(12) United States Patent 

Bowman-Amuah 



US006636242B2 

(10) Patent No.: US 6,636,242 B2 
(45) Date of Patent: *Oct. 21, 2003 



(54) VIEW CONFIGURER IN A PRESENTATION 
SERVICES PATTERNS ENVIRONMENT 

(75) laveotor: Miche] K. Bowman-Amuah, Colorado 
Springs, CO (US) 

(73) Assignee: Accenture LLP, Palo Alto, CA (US) 

( * ) Notice: This patent issued on a continued pros- 
ecution application filed under 37 CFR 
1.53(d), and is subject to the twenty year 
patent term provisions of 35 U.S.C. 
154(a)(2). 

Subject to any disclaimer, the term of this 
patent is extended or adjiisted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/387,580 

(22) Filed: Aug. 31, 1999 

(65) Prior Publication Data 

US 2003/0058277 Al Mar. 27, 2003 

(51) Int. CI.'^ , G06F 3/14 

(52) U.S. CI 345/764; 345/762; 345/765; 

345/744; 345/733 

(58) Field of Search 345/333, 335, 

345/329, 339, 965, 966, 427, 428, 762, 
765, 744, 733, 764; 709/217, 201; 705/5 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,047,918 A 9/1991 Schwartz et al 707/203 

5,133,075 A 7/1992 Risch 707/201 

5,187,787 A 2/1993 Skeen et al 709/314 

5,241^80 A 8/1993 Babson, III 379/15 

5,291,593 A 3/1994 Abraham et al 707/103 

5;301,270 A 4/1994 Steinbeig et al 345^26 

5,301,320 A 4/1994 McAttce ct ai 395/650 

5,313,636 A 5/1994 Noble et al 707/1 

5,414,812 A 5/1995 Filip et al 707/103 

5,434,978 A 7/1995 Dockter et al 709/230 

5,437,038 A 7/1995 SUberbauer et al 395/700 



5,457,797 A 10/1995 Butterworth et al 709/302 

5,463,686 A 10/1995 Lebourges 379/220 

5,471,629 A 11/1995 Risch 707/201 

5,475,844 A 12/1995 Shiramizu ct al 709/104 

5,499,371 A 3/1996 Henninger et al 717/2 

5,560,005 A 9/1996 Hoover et al 707/10 

5,568,644 A 10/1996 NcUon ct al 395/741 

5,581,758 A 12(1996 Burnett et al 707/103 

5,606,664 A * 2/1997 Brown et al 709/224 

5,623,418 A 4/1997 Rostokcr et al 716/1 

5,642,511 A 6/1997 Chow et al 395/701 

5,649,139 A 7/1997 Weinreb et aL 707/202 

5,671,386 A 9/1997 Blair ct al 395/405 

(List continued on next page.) 

FOREIGN PATENT DOCUMENTS 

EP 0123456 A2 1/2000 100/100 

WO WO92/01251 1/1992 

WO WO 99/08208 2/1999 G06F/17/30 

(List continued on next page.) 

OTHER PUBUCAnONS 

Kovalerchuck et al., comparison of relational methods and 
attribute-based methods for data mining in intelligent sys- 
tems, proceedings of the 1999 IEEE, International Sympo- 
sium on Intelligent Systems and Semiotics, Cambridge, MA, 
PP 162-166. Date Sep. 1999. 

(List continued on next page.) 

Primary Examiner — Steven Sax 

Assistant Examiner — Thomas T Nguyen 

(74) Attorneyj Agent, or Firm — Oppenheimer Wolff & 

Donnelly LLP 

(57) ABSTRACT 

A system, method and article of manufacture are provided 
for assigning a view to an activity. Notificadon is received 
that a startup event of an activity has occurred. A reference 
to a first instance of an object created by the startup event of 
the activity is also received. A view to launch is determined 
in response to the receipt of the notification and the refer- 
ence. The view is based on predetermined criteria. The view 
is associated with the activity and displayed. 

17 Claims, 123 Drawing Sheets 



Bigness Pfocess Componeni 



_Pfooa»8Defhion 



Server 




UswhtertacoConvponent 



06/17/2004, EAST Version: 1.4.1 



us 6,636^42 B2 

Page 2 



U.S. PATENfT DOCUMENTS 



5,675,748 A 10/1997 Ross 395/284 

5,611,991 A 10/1997 Talatik 706/45 

5,680,602 A 10/1997 Bloem et al 707/1 

5,692,107 A 11/1997 Simoudis ct al 706/12 

5,706,506 A 1/1998 Jensen et al 707/103 

5,708,828 A 1/1998 Coleman 395/785 

5,710,901 A 1/1998 StodghiU et al 345/339 

5,715,397 A 2/1998 Ogawa et al 395/200.18 

5.721.908 A ^1998 Lagarde et al. 

5,724,575 A 3/1998 Hoover et al 707A0 

5,732,263 A 3/1998 Havens et al 707/103 

5,732,270 A 3/1998 Foody et al 709/303 

5,737,607 A 4/1998 HamUtoo ct al 395/701 

5,751,965 A ♦ 5/1998 Mayo et al 709/224 

5,758,351 A 5/1998 Gibson 707/104 

5.761.513 A 6/1998 Yellin et al 395/705 

5,764,235 A 6/1998 Hunt ct aL 345/428 

5,764,955 A 6/1998 Doolan 709/223 

5,768,510 A ♦ 6/1998 Gish 709/203 

5,774,660 A 6/1998 Brcndel et al 709/201 

5,778,368 A 7/1998 Hogan et al 707/10 

5,787,413 A 7/1998 Kauffman et al 707/2 

5,799^10 A 8/1998 Anderson ct al 707/102 

5,867,153 A 2/1999 Grandcolas et al 345/326 

5.870.742 A 2/1999 Chang et al 707/8 

5,870,746 A 2/1999 Knutson ct al 707/101 

5,872,973 A 2/1999 Mitchell et al 709/332 

5,873,086 A 2/1999 Fuju et al 707/10 

5,878,408 A 3/1999 Van Huben ct al 707/1 

5,890,133 A 3/1999 Ernst 705/7 

5.892.909 A 4/1999 Grasso ct al 709/201 

5,896,383 A 4/1999 Wafceland 370/400 

5,898,870 A 4/1999 Okuda et al 709/104 

5,905,873 A 5/1999 Hartmann el al 395/200.79 

5,905,897 A 5/1999 Chan et al 395/733 

5,907,704 A 5/1999 Gudmundsoa et al 395/701 

5,909,540 A 6/1999 Carter et al 714/4 

5,915,115 A 6/1999 Talati 717/5 

5,920,703 A 7/1999 Campbell et al 395/200.66 

5,933,816 A 8/1999 Zeannah et al 705/35 

5,940,075 A 8/1999 Mutschler, III et al 345y335 

5,940,594 A 8/1999 Ali ct al 709/203 

5,946,694 A 3/1999 Copeland et al 707/103 

5,946,697 A 8/1999 Shen 707/104 

5,953,707 A 9/1999 Huang ct al 705/10 

5,958,012 A ♦ 9/1999 Battat et al 709/224 

5,960,200 A 9/1999 Eager et al 717/5 

5,966,451 A 10/1999 Utsumi 380/49 

5,987,247 A 11/1999 Lau 717/2 

5,987,501 A 11/1999 HamUton et al 709/203 

5.987.514 A 11/1999 Rangarajan 709/224 

5,987,633 A 11/1999 Newman ct al 714/712 

5,995,753 A 11/1999 Walker 717/2 

5,995,945 A 11/1999 Notani et al 705/28 

5,999,948 A 12/1999 Nelson 

6,006,230 A 12/1999 Ludwig et al 707/10 

6,016,394 A 1/2000 Walker 717/1 

6.018.743 A 1/2000 Xu 707/103 R 

6,023,722 A 2/2000 Colyer 709/201 

6,029,174 A 2/2000 Sprenger et al 707/103 

6,029,177 A 2/2000 Sadiq et al 707/201 

6,032,153 A 2/2000 Sadiq et al 707/103 

6,035,303 A 3/2000 Baer et al 707/103 

6,038,598 A 3/2000 Danncels 709/219 

6,041,365 A 3/2000 Kleinennan 709/302 



6,052,739 A 4/2000 Bopardikar ct al 709/301 

6,057,856 A • 5/2000 Miyashita et al 345/435 

6,070,191 A 5/2000 Nareadran et aL 709/226 

6,078,960 A 6/2000 Ballard 709/229 

6,081,837 A 6/2000 Stedmanctal 709/219 

6,083,276 A 7/2000 Davidson et al 717/1 

6,085,198 A 7/2000 Skinner et al 707/103 

6,092,118 A 7/2000 Tsang 709/246 

6,108,703 A 8/2000 Leighton et al 709/226 

6,115,752 A 9/2000 Chauhan 709/241 

6,125,359 A 9/2000 Lautzcnhciscr ct al 706/60 

6,128,279 A 10/2000 O'Neil et al 370/229 

6,141,660 A 10/2000 Bach et al 345/352 

6,141,759 A 10/2000 Braddy 713/201 

6,144,991 A ♦ 11/2000 England 709/205 

6,148,335 A U/2000 Haggard et al 709/224 

6,148,361 A 11/2000 Oipcntcr et al 710/260 

6,154,212 A • 11/2000 Eick et al 345/356 

6,157,940 A 12/2000 Marullo et al 709/22 

6,182,182 Bl 1/2001 Bradley et al 710/129 

6,202,099 Bl 3/2001 GiUies et al 709/317 

6,223,209 Bl 4/2001 Watson 709/201 

6,243,761 Bl 6/2001 Mogul et al 709/246 



FOREIGN PATENT DOCUMENTS 



WO 


wo 99/44155 


9/1999 


WO 


PCT/USOO/23885 


8/2000 


wo 


PCT/USOO/23999 


8/2000 


wo 


PCT/USOO/24082 


8/2000 


wo 


PCr/USOO/24083 


8/2000 


wo 


PCr/USOO/24084 


8/2000 


wo 


PCT/USOO/24085 


8/2000 


wo 


PCT/USOO/24086 


8/2000 


wo 


PCT/USOO/24125 


8/2000 


wo 


PCr/US/OO/24188 


8/2000 


wo 


PCr/USOO/24189 


8/2000 


wo 


PCr/USOO/24236 


8/2000 



OTHER PUBUCAnONS 

Kinexis. Object-orientation and Transaction Processing 
Where Do They Meet. OOPSLA Keynote, Oct. 6-11, 1991, 
Lec ct aL Path Dictionary: A New Access Method for Query 
Processing in Object-oriented Databases. IEEE Transac- 
tions on Knowledge and Data Engineering, vlO, n3, May./ 
Jun. 1998. 

Buddnis ct aL Enacting Authorization Models for Object-o- 
riented Databases. Database and Expert Systems applica- 
tions. Proceedings, Seventh International Workshop, Sep. 
WO, 1996, pp. 116-121. 

Bertino et al. Trigger Inheritance and Overriding in an 
Active Object Database System. IEEE Transactions on 
Knowledge and Data Engineering, vl2, n4. Jul./Aug., 2000. 
ANSn Standard for the Programming Language C++, First 
Edition ISOAEC 14882: 1998. Date Sep. 1998. 
The Annotated C++ Reference Manual ANSII Base Docu- 
ment, MA. Ellis and B. Stroustrup. Date Jul. 1990. 
IBM Dictionary of Computing, pp. 140, 241, 299, 728. 
Microsoft Corporation, Microsoft Solutions Framework 
Overview A Quick Tour of the MSF Models, URL: hltp:// 
channels.microsoft.com/enterprise/support/support/consult, 
Viewed Oct. 9, 1999. 

* cited by examiner 



06/17/2004, EAST Version: 1.4.1 



S. Patent Oct.21,2003 sheet 1 of 123 us 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 2 of 123 



US 6,636,242 B2 



200 




Tadt Knowledge of the System Components and Interrelationslilps 



t 

Bu8ci5 



Applicabons 



Provides services to 



Fig. 2 



Manages 



SAF 
300 



Provides^ 

services to / 

/ Builds 



Execution 
Architecture 



Provides 
\ services to 
Manages \ 



Development 
Architecture 



304 



Builds 



Manages — 



Operations 
Architecture 



306 



Fig. 3 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 3 of 123 us 6,636,242 B2 



400 



Application Style 
404 



Technology Generations 402 



Knowledge 
Management 



Dedsion 
Support 



Collaboration 



Integration 



Batch 



Host 



Client/ 
Server 



Network 
Centric 



Delivery 
Vehicle 



OLTP 



Fig. 4 



Knowledge 




Fig 5 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 4 of 123 US 6,636,242 B2 



Existing 
Architecture and 
Infrastojcture 
600 



Business 
Imperatives 




Fig. 6 



B1. The client needs to reach a new external audience 

with this application. 
B2. The dient needs to reach a large or diverse 
internal audience with this application* 



Business Impera^es 

m 



Existing Architecture 
and Infrastructure 
ZQO 



Networt^-Centric 
Architecture 



IT Guiding 
Principles 



m 



El. Other Network-Centric applications 
have been developed and 
placed in production. 

E2. The client has significant technology 
skifls within Its ITdepartmenL 

E3. The client has multiple hardware/ 
operating syslem configurations 
for their dient machines. 

E4. The application will run on a 
device other than a PC, 

E5. The cun-ent legacy systems 
can scale to serve a potentially 
large new audience. 



G1. The dient is an early adopter 
of new technology. 

G2. Applications should be developed to 
handle non-dedicated 
or occasional users. 

G3. Where appropriate, applications 
should be developed 
with multknedia capabilities 
for the presentation of data 
(text, sound, video, eta). 
G4, The Execution, Operation and Development 
architectures will be designed 
to support frequent releases of 
enhancements/modificalions 
to production applications. 



Fig. 7 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 5 of 123 US 6,636,242 B2 




o 

00 



.e8 



CO 



CO 

■§ 



CD 
CO 





2 


aS 






03 




CO 








"c 


1 






b 





o 

CO 




CO 




al 8 



ir-s o ^ c 

S £ c t2 ^ 
CO w S 55 



§• ® = 2 

0"S TO ^ 

S CO o <o 

o 



LU 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 6 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 7 of 123 



US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 8 of 123 US 6,636,242 B2 



E 



CO 

a> 
cx 
O 



CO 



J 



0) 

E 

c: 

2 
*> 
c 
UJ 



CO 

(D 
O 

& 

E 



g 

o 

CO 



CO 

% 



€0 

o 
c 

S 

-s 

f 




CQ 

O) 
CO 



CO 



o 
O 

XI 

s- 

8 



-8 



o 

I 



en 



so 



c: 




8' 



O 

s 




o 

1 



E 
E 
o 
O 



"cS S 
•11 

J> E 
I— UJ 




C8S6 

Management 


Document 
Management 


Folder 
Management 










Data 
Sharing 


Local 








Database 


Database 
Access 


Synchron- 
teatlon/ 
Replication 






06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 9 of 123 



US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 10 of 123 



US 6,636,242 B2 



1000 



Window 
Syst«n 



1300 



1002 



Desktop Manager 



m 



Fonm 



1304 



User 

Navigation ^ 



Browser Extension 1310 


Fomri ^ 


User Navigation 



1308 



Report & Print 


Direct Manipulation 







input Device 



1004 



Database Services 
1402 



Document Services 
1416 



Versioning 

1418 





Replication/Synchronization 


1404 




Access 


1408 




Security 


1410 
,.J 




Indexing 


1412 
I-" 




Storage 


m 



1320 



Fig. 13 



Fig. 14 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 11 of 123 US 6,636,242 B2 



1006' 



1008 



Virtual Resources 1502 


Fax 1510 


Terminal 1518 


File Sharing 1512 


PrinUng 1520 


Paging 1514 


AudioAfldeo 1K2 


Phone 1516 





Directory ^ 
Services — 



Domain 1524 



Name 1526 



Messaging 



1506 



Core 



1528 



File Transfer 1530 



RPC 



1532 



Msg- 
Ofiented 



1534 



Streaming 



1536 



Specialized 1S38 



E-Mail IMQ 



Database 
Access 



1542 



ORB 



1544 



CTI 



1546 



EDI 



1548 



Legacy 
Integration 



1550 



Communications 
Security 
1508 



Encryption 1552 



Authorization 1554 



Authentication 1556 



1512 



Fig. 16 



CLIENT 



root/ 



SERVER 



root/ 



uin II etc 


usr 


acx:t 




acct 


usr 


etc 




AC* 




Connections 







payri [ I budg 
mounted directories 



bin 



ocal directories 



budg payri 

local directones that are being 
remotely mounted 



Fig. 16 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 12 of 123 



US 6,636,242 B2 



Client 


Send 


Receive 


Server 


(Application 1) 




(Application 2) 



Fig. 17 



Client 
(Application 1) 



Queuing 




Server 
(Application 2) 



Fig. 18 



Application 1 
(Putillsher) 






Subscriber 1 


Subscriber 2 




Subscriber 3 



Fig. 19 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 13 of 123 US 6,636,242 B2 




Stream 



Fig. 20 




Client 



. ^^ CC 

' run- 


)M ^ 
time . 


Security 
Provide 


DCERPC 


Protocol Stack 



COM 
k run-time 



Security 
Provide 



< — ^Component 



DCERPC 



Protocol Stock 



Q network j 
\ ^protocol 



Fig. 22 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21,2003 



Sheet 14 of 123 



US 6,636,242 



Client 



2M 




message 
mapping 



CTI 
Server 
2302) 



III 



Telephony 
Network 
2306 



device-specific 
communication 



PBX/ACD 




2304 



1010 



Transport Services 2402 



Message Transport 



2m 



Padtet 
Fonwarding/lntemetwofking 



Transport 
Security 
2410 



Networl( Media 
Services 
2416 



Fig. 23 



Circuit Switching 

m 



Network Address 

Allocation 
2412 



Quality of 
Service 
2414 



Media Access 



2418 



Physical Media 

^ 



Fig. 24 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet IS of 123 US 6,636,242 B2 



Nehvork Node 






Physical 
Connector 




Physical Media 
{wired or wireless) 2504 







Fig. 25 



1012 



1014 



TP 
Monitor 



2602 



Resource 
Management 



2m 



Transaction 
Management 



fi06 



Transaction 
Partitioning 



2608 



Fig. 26 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 16 of 123 



US 6,636,242 B2 



1016 



1018 



Runtime Services 2702 



Language 
Interpreter 



zm 



Virtual Machine 
2706 



Component 
Framework 



27.6 



System Services 
2708 



System Security 
2710 



Proffle 
Management 

2m 



Environment 
Verification 

2714 



Task & Memory 
Management 
2Z16 



Application Sewices 2718 


Application 
Security 
2720 


Error Handling/ 
Logging 

2725 




State 
Management 
2724 


Codes Table 
Services 

2Z26 


Active Help 
2728 


RIe Services 
2730 




Other Common 
Services 

2732 


Appl. Integration 
Interface 

2731 





Operating System 



Fig. 27 



1020 



Base Services 



Web Server Services 


2820 




Push/Pull Services 


2840 




Batch Services 


2860 




Report Sen/ices 


2880 




Workfkw Services 


2890 



Fig. 28 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 17 of 123 US 6,636,242 B2 



Report 
Table 
DB 



Report 
Request ~ 
from Client 



Network 




Report 




Report 


File 




Distribution 


DB 




DB 



/ \ 



Report 
Initiation 

2900 




Report 
Execution 

2902 




Report 
Distribution 

2904 







\ 



Server 3000 



Database 
Recovery 



Application 



Database 
Updater 



Open 
Interface 
Manager 



LAN 
Comms 
Broadcast 



Report 
Process 



Environment 
Manager 



Event 
Manager 



Printer 

-^Screen 

Archive 

Fig. 29 



Workstation 3002 



1-AN 
Comms 
Distributor 



Environment 
Manager 



User 
Interface 
Application 



Workstation 3002 



LAN 
Comms 
Distributor 



User 
Interface 
Application 



Environment 
Manager 



Fig. 30 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 Sheet 18 of 123 



US 6,636,242 B2 




Report Status Table 



Report Writer Process 
3102 






Order Report 
Writer 


Trade Report 
Writer 


Trade Slip 
Writer 


Other Report }i 
Writers 











Generated Reports FIQ. 31 



Architecture Manager Library 
3200 




Report 
Process 






Fig. 32 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 19 of 123 US 6,636,242 B2 



1022, 1024 



Business Logic 








Interface 


Application Logic > 


^ Data Abstraction 






3300/ 


3302 X 


3304 





Fig. 33 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 20 of 123 



US 6,636,242 B2 




Fig. 34 



Logical 
Perspective 



Physical 
PerspecCve 




Fig. 35 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 21 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 22 of 123 us 6,636,242 B2 




Fig. 38 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. n, 2003 sheet 23 of 123 US 6,636,242 B2 



(Workflow 
Design ^ 



Dialog Flow 
Design 



3904 ^ 



'^Userlnterfece ...^ 
Design 2286 




Business Process Component 
Process Definition 



Fig. 39 

Business Entity Component 




User Interface Component 



Fig. 40 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 24 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 25 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 26 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 27 of 123 US 6,636,242 B2 



Traditional npganly^finn 



Arohjtecture-Based Onqai] \j;Riinr^ 



Activities 




Credit/ 
Collect'ons 




Billing 




Rnance 


4502 




ISM 




4506 




4510 



Tedinical 
Architeclure 



Fig. 45 



4600 



Inteiface 
View Team 

Component/Object 

Domain 

Model 



■n Server or 
J Data Access 
Services 



I Frameworlcs 



Technical 
Architecture 



Fig. 46 



06/17/2004, EAST Version: 



1.4.1 



U.S. Patent Oct, 21, 2003 Sheet 28 of 123 US 6,636,242 B2 



Workcell Ap proach 



Activities 



4702 



Credit/ 
Collections 



4704 



Billing 



4706 



Finance 



4710 



Technical 
Architecture 



Frameworks 



Interface 
View 

Object 
Domain 
Mode! 

Server or 
Data Access 
Services 



Fig. 47 



. Business 



Technology 



Environment 




Business Requirements 



Data Architecture 



Application Architecture 



Infrastructure 



System Software 



Hardware/Network 




Business 
Perspective 



Systems and 
Technology 
Perspective 



Fig. 48 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct, 21, 2003 Sheet 29 of 123 US 6,636,242 B2 



Benefits 
Cost 



Business Case 



Functional/Use 
Requirements 

Technical 
Requirements 

Quality 
Requirements 



Requirements 
Definition 



System 
Design 



Technical 
Design 



Program 
Spedflcatlon 



Detailed 
Design 




Benefits 
Realization 
Test 



Operational 
Readiness 
Test 



7 



Product 
Test 



Assembly Test 



Composer 
Test 



z 



ConstnjcBon 



\^ Row of Work 

O Verification 



Validation 
— 4902 

Test that the product 
implements the spedficatbns 
4904 



Fig. 49 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 30 of 123 US 6,636,242 B2 



O 

in 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 31 of 123 US 6,636,242 B2 




Ll_ 



E 
E 

CO 

o 
c 

<D 



E 
S 

O) 
CO 

3 
B 
S 

CO 



E 
























o 





So 

o w 



C/5 

E 
I 

O 
CO 

75 

13 

%n 

s 



O 





a> 

CO 




06/17/2004, EAST Version: 1,4. 1 



U.S. Patent Oct. 21, 2003 sheet 32 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 33 of 123 



US 6,636,242 B2 



5400 





RECEIVING DATA 

5402 








f 






TRANSFORMING THE DATA INTO A PLURAUTY OF 
CONCRETE OBJECTS 


5404 




r 


ASSXIARNG EACH OF THE CONCRETE OBJECTS WITH 
AN ABSTRACT INTERFACE 

5406 






CREATING A MAP OF THE ASSOCIATION BETWEEN THE 
CONCRETE OBJECTS AND THE ABSTRACT INTERFACE 

5408 



RECEIVING A REQUEST INCLUDING AN IDENTIRER FOR ONE OF 
THE CONCRETE OBJECTS AND AN IDENTIFIER FOR THE 

ABSTRACT INTERFACE 54^0 



CONSULTING THE MAP TO LOCATE THE CONCRETE OBJECT THAT 
HAS BEEN IDENTIFIED 



CREATING AN ABSTRACT OBJECT THAT CORRESPONDS TO 
THE LOCATED CONCRETE OBJECT 

5414 



Fig. 54 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 34 of 123 us 6,636,242 B2 



5500 



PROVIDING m ABS'i"RACT CLASS OF ABSTRACT DATA REQUIRED 
BY A PLURALITY OF BATCH JOBS 

5502 




r 


DEFINING A PLURALITY OF BATCH JOB SUB-CLASSES EACH 
INCLUDING BATCH SPECIFIC DATA, AND LOGIC FOR PROCESSING 
THE ABSTRACT DATA AND THE BATCH SPECIFIC DATA UPON THE 

EXECUTION THEREOF 

5504 




r 


REPRESENTING EACH OF THE I 

ANOE 


3ATCH JOB SUBCLASSES WITH 
JJECT 

5506 



IDENTIFYING ONE OF THE OBJECTS 

5508 



EXECUTING THE LOGIC OF THE BATCH JOB SUB-CLASSES 
ASSOCIATED WITH THE IDENTIFIED OBJECT 

5510 



Fig. 55 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 35 of 123 US 6,636,242 B2 



BatchJob 



5600 



name 

status 

priority 

messages 

timeSubmitted 

timeStarted 

timeCompleted 



preRunQ 
run() 

postRunO 
class 
startAllPendingO 




BittCustomer 
BatchJob 



customerlD 
periodStartTime 
. periodEndTime 



5602 



preRunO 
runO 

postRunO 
class 
StartAllPendingO 



Fig. 56 



5700 



1 



Batch 
Sd)eduler 
(Maestro) 



startAilPending 
return successO 



BillCustomer 
BatchJob 
(dass) 

5702 



perfomiRunO 
return success 



1.22 i 



1,1 



selectrBiliCustomer 
BatchJob" 
"Pending") 
return pendingjobs 

runO 
return success 



1.2 



1.21 



BillCustomer 

BatchJob 
<aPendingJob> 

3504 



1.23 



preRunQ 
retum void 

1.2.21 



billCustomer( 
customerlD) 



log messages 



postRunO //log messages to files 
retum void 



RDBMS 



//setup message files 



Bill 
Component 
<theBillComponent> 



Fig. 57 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 36 of 123 



US 6,636,242 B2 



5800 



STORING A PLURALITY OF ATTRIBUTE VALUES FOR A BUSINESS 
OBJECT IN AN ATTRIBUTE DICTIONARY 

5802 



PROVIDING A PLURAUTY OF ATTRIBUTE NAMES IN THE 
ATTRIBUTE DICTIONARY FOR THE STORED AHRIBUTE VALUES 

5804 



VERIFYING THAT A CURRENT USER IS AUTHORIZED TO EITHER 
SET OR GET ONE OF THE ATTRIBUTE VALUES UPON A REQUEST 
WHICH INCLUDES THE ATTRIBUTE NAME THAT CORRESPONDS 
TO THE ATTRIBUTE VALUE 5306 



OBTAINING OR UPDATING THE ATTRIBUTE VALUE IN THE 
ATTRIBUTE DICTIONARY IF THE VERIFICATION IS SUCCESSFUL 

5808 



BROADCASTING AN INDICATOR UPON THE AHRIBUTE VALUE 

BEING UPDATED 

5810 



Fig. 58 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 37 of 123 



US 6,636,242 B2 



5900 



PREPARING TO PERFORM A SERIES OF PROCESSING STEPS ON 
INPUT OBJECTS BEING STREAMED INTO A BATCH PROCESSING 

SYSTEM 

5902 



ENCAPSULATING EACH OF THE PROCESSING STEPS 
WITHIN A FILTER 



i904 



RECEIVING AND PROCESSING THE INPUT OBJECTS IN THE 

FILTERS 



906 



DELIVERING RESULTS FROM THE FILTERS INCREMENTALLY 
DURING PROCESSING OF THE INPUT OBJECTS FOR REDUCING 
LATENCY AND ENABLING PARALLEL PROCESSING 



5908 



UTILIZING CONNECTORS FOR CONNECTING AT LEAST TWO 
FILTERS EACH HAVING A PROCESSING STEP FOR CREATING A 
PROCESS, WHEREIN ONE OF THE FILTERS IS AN INPUT FILTER OF 
THE PROCESS AND ANOTHER OF THE RLTERS IS AN OUTPUT 

FILTER OF THE PROCESS ^ 



USING CONNECTORS FOR CONNECTING INPUT AND OUTPUT 
FILTERS OF.DIFFERENT PROCESSES FOR FORMING A SCALABLE 

SYSTEM ^ 



Fig. 59 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 38 of 123 



US 6,636,242 B2 



AttributeDictionary 



6002 



attributeValues 



getAttribute 
setAttribute 
attributeNames 



1 



Contains ^ 



get 
put 

oontainsKey 
keyset 



Client to 



AttributeDictionaryClient 



6000 
i 



attributeDiotionary 



getAttribute 
setAttribute 
attributeNames 



Throws 



AttributeNotFoundException 



throw 



HashMap h^^O^ 



Fig. 60 



Description 



Set the attribute value in the 
attribute dictionary. 

Sei the value of the attribute 
in the HashMap. 



AttributeDictionary 



6100 
i 



AttributeValues 
HashMap 



setAtlribute("balance" 



Float) 



put("balance", Roat) 



Fig. 61 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 39 of 123 US 6,636,242 B2 



o 

I 

c 

=3 

I 

-ffi 



CM 
CO 



CO 
CO 

d) 



o 
o 




i 

B 
c 
o 
o 



§ 





I 

o 

CO 

o 



CO 

IS- 



•IS o. 



c E 

CO a> c 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 40 of 123 



US 6,636,242 B2 



6400 



PROVIDING A PLURALITY OF CONSTANT NAMES EACH HAVING A 
CORRESPONDING CONSTANT VALUE 

6402 



GROUPING THE CONSTANT NAMES INTO CONSTANT CLASSES 
BASED ON AN E^JnTY WHICH THE CONSTANT VALUES 
REPRESENTS 

6404 



ALLOWING ACCESS TO THE CONSTANT VALUES BY RECEIVING A 
CALL INaUDING THE CORRESPONDING CONSTANT NAME AND 
CORRESPONDING CONSTANT CLASS 

6406 



Fig. 64 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 41 of 123 US 6,636,242 B2 



6500 



DEFINING A SENDING FIXED FORMAT CONTRACT ON INTERFACE 
CODE FOR A SENDING SYSTEM AND A RECEIVING FIXED FORMAT 
CONTRACT ON INTERFACE CODE FOR A RECEIVING SYSTEM 
5502 



TRANSLATING A MESSAGE TO BE SENT FROM THE SENDING 
SYSTEM TO THE RECEIVING SYSTEM BASED ON THE SENDING 
FIXED FORMAT CONTRACT 

6504 



SENDING THE MESSAGE FROM THE SENDING SYSTEM 

6506 



RECEIVING THE MESSAGE BY THE RECEIVING SYSTEM 

6508 



TRANSLATING THE MESSAGE RECEIVED BY THE RECEIVING 
SYSTEM BASED ON THE RECEIVING FIXED FORMAT CONTRACT 

m 



Fig. 65 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 42 of 123 US 6,636,242 B2 



Object-based 
System 
(Objects) 

6600 



6602 



^^^.g ^treatn-on ) stream-off ^ ^.grU 



streanH)ff 



stream-on 




Fig. 66 



6700 



Save 


Jimbo 


Jones 


161 Clark St 


Chicago 


# • • 





Fig. 67 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 43 of 123 US 6,636,242 B2 



Fixed 
Formal 
contract 



Fixed 

Format 

contract 




6802 



itream-on 



strea 



□□□□□□□□□□□a 



strearrwrff 



streanoon 



□□□□□□□□□□□□a 



Fixed 
Format 
contract 




Fixed 
Format 
contract 



Fig. 68 



Fixed 

Format 

contract 

6900 



Fixed 
Format 
contract 
6900 




;tream-on 



streai 



□□□□□□□□□□□a 




stream-off 



stream-on 



Fixed 
Format 
contract 
6900 



□□□□□□□□□ □OpQ n y 



Fixed 
Format 
contract 



Non-Object 
System 
(Strings & 
Structures) 



cics 




Fig. 69 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 44 of 123 us 6,636,242 



7004 



7002 



Object-based System 

im 



Customer 
Object 



Fixed Format contract 
definin9th6 object- 
iised during streamOn. 




Tred-('Male') 25 



Non-O^ect System 
7006 



Fixed Format oontract 
defining the data and data 
structure-used 
during un-streaming 



'Male' I 

5Z 



'2? 





Male 


22 






























7 



7008 

Fig. 70 



I wish I could 
find some Services! 





I support the following services: 

-Seiivesl 

-Service 2 




Fig. 72 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 45 of 123 US 6,636,242 B2 



7100 



PROVIDING A PLURALITY OF INTERFACES 








r 


ALLOWING ACCESS TO A PLURALITY OF DIFFERENT SETS OF 
SERVICES FROM EACH OF THE INTERFACES, WHEREIN EACH 
INTERFACE HAS A UNIQUE SET OF SERVICES ASSOCIATED 

THEREWITH ^ 






NAMING EACH OF THE INTERFACES WITH A NAME INDICATIVE OF 
THE UNIQUE SET OF SERVICES ASSOCIATED THEREWITH 




7106 






BROADCASTING THE NAVIES OF THE INTERFACES TO A 
PLURALITY OF SYSTEMS REQUIRING SERVICE 




7108 



Fig. 71 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 46 of 123 US 6,636,242 B2 




Change 



GetCustomerName 
Phone I 



7302 

Gel Customer Phone 
Get Customeh^ddress 



I wish I could find 
some Services! 




Great! The Naming 
Service knows 
some services! 



Come 

andSeUfl 
Browse and Update 
services available 
here! 



Fig. 73 



Naming 
Service 



Change Customer 
Change Address 




77 

ss ^( 



\pet Customer Phone 
Get Customer Address 
GetCustomerName 



Change Phone 



Fig. 74 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 47 of 123 US 6,636,242 B2 




Network 

1a.bind( 
'Update Interface", 
Remote Object 
Reference 



4. relum(remote 
object reference) 



3. resolveCBrowsing 
Interface"); 



1b. bind( 
"Browsing Interface", 
Rentote Object 
Reference) 





5, getCustomer 
("1234") 

\ 



12. Return aCustomer 
Structure 
for display in a Ul 




|7.getCustomer("^Byy 
.,getCustomerA(ldr(td) 
>!getCustomerPhone(ld)l->-^ 



11, Return aCustomerStnjcture 




9. retum(customer 
data #1234^ 



10. Create Customer 
structure 



aCustomerStnicture 
-1234 
-AcHve 
-Jimbo 
-Jones 
-Good 




Fig. 76 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 48 of 123 US 6,636,242 B2 



7700 

V 



PROVIDING A PLURAUTY OF COMPONE^^■S COUPLED TO AT 
LEAST ONE CUENT VIA A COMPONENT INTEGRATION 
ARCHITECTURE FOR SERVICING THE CLIENT 

ZM 










INTERCONNECTING A LEGACY SYSTEM TO THE CLIENT VIA THE 
INTEGRATION ARCHITECTURE USING A LEGACY WRAPPER 






7704 






r 


INTERFACING THE LEGACY SYSTEM AND THE CLIENT VIA THE 
LEGACY WRAPPER BY COMMUNICATING WITH THE CLIENT BY 
WAY OF A FIRST PROTOCOL AND BY COMMUNICATING WITH THE 
LEGACY SYSTEM BY WAY OF A SECOND PROTOCOL 

7706 



Fig. 77 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 49 of 123 US 6,636,242 B2 




Component Integration Architecture 7804 

..rrrv. _rrrv, v\A/x 













Component 




Component 




Legacy System 










7806 



Fig. 78 




Component Integration Architecture 7904 



roio-i roio-, r<jxyn 



Component 



Component 



Component 

K>0<>i 

Legacy System 



7900 



7901 



Fig. 79 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 50 of 123 US 6,636,242 B2 



Client 

8006 



Component 
Model 

8002 



I 



8000 



Component Integration Architecture 8008 | 

roich roix>i roich 



Component 




Component 




Legacy 






8010 




Component 



Legacy 
Conr^ponent 
8004 



Legacy Wrapper Component 

mi 



Component Adapter 8014 



Legacy Integration Architectjre 
8016 



Legacy Adapter 8018 I 



Legacy System 802Q 



Legacy Wrapper Component 8112 



Component Adapter SU^ \ 



1 



Legacy Integration Architecture 
8116 



I 



Legacy Adapter MIS 

AAA 



Legacy System 8120 



Fig. 80 



Fig. 81 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 51 of 123 US 6,636,242 



8222' 



Legacy Wrapper Component 

i Z_ 8212 



Component Adapter 
S214 



Legacy Integration Architecture ^^^g 



Legacy Adapter 



8218 



Legacy System 





Client 



jomponent Integration Arcmtecture 



Legacy Wrapper Component 





Fig. 82 



8300 

J 



Fig. 83 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 52 of 123 US 6,636,242 B2 



8400 



) 



PROVIDING A PLURALITY OF GLOBALLY ADDRESSABLE 
INTERFACES AND A PLURALITY OF LOCALLY ADDRESSABLE 

INTERFACES 



8402 



ALLOWING ACCESS TO A PLURALITY OF DIFFERENT SETS OF 
SERVICES FROM EACH OF THE GLOBALLY ADDRESSABLE 
INTERFACES AND THE LOCALLY ADDRESSABLE INTERFACE. 
EACH INTERFACE HAVING A UNIQUE SET OF SERVICES 
ASSOCIATED THEREWITH 

8404 



REGISTERING THE GLOBALLY ADDRESSABLE INTERFACES IN A 
NAMING SERVICE FOR FACILITATING ACCESS THERETO 



8406 



PERMITTING USE OF THE LOCALLY ADDRESSABLE INTERI^CES 
ONLY VIA THE GLOBALLY ADDRESSABLE INTERFACES OR 
ANOTHER LOCALLY ADDRESSABLE INTERFACE 

8408 



Fig, 84 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 53 of 123 



US 6,636,242 B2 



8500 

V 



I guess that interface 
isn't secure. 




Client 



I'll just maintain that 
server myself 



8502 

tcol^up Blue 
Interface 



The interface is my list of 
registered servers, 
so ril give it out to 
anyone. Here you go! 



8504 
8506 I Sen/er 




Register y \ " 
Interfac e Interface 



Lookup Red 
Client Unterface 



Lookup Purple 
Interface 





(secure Interface 

Fig. 85 



I guess that internee 
is off limits 




8600 



^Server^ 



Client 



I guess I shouldn't 
maintain that Server 



Lookup Blue 
Interfao^ 




^Lookup 
Client Interface 



7 




V LocalJLAI) 

/ Global(6A 
Reoister A Interface 
Inteiface 




Interface^ GlobaMGAl 
Interrace 



Wow! tNsisaiot 
fasterl 



Lookup Purple 
internee 




Register. 
Interfece 




Register 
Internee 




Client 



Glot>al(GAI} ^ 
IfTterface J 



Fig, 86 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct 21, 2003 sheet 54 of 123 US 6,636,242 B2 



Lookup 

UghtBlue 
Interface / 
Reference to 
Interface 




Naming 

or 
Trading 
Service 



- Register 
UghtBlue 
(GAI) ^ 
Interface 



Get Yellow Interface 



Reference to Local Interface 



Call operation on Local Interface 



Network 



Get Reference 
to 

4802 Local! , 
( Interface 




Fig. 87 



Network 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 55 of 123 



US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 56 of 123 US 6,636,242 B2 



9000 



COMMUNICATING A QUERY FROM A FIRST 
SYSTEM TO A SECOND SYSTEM TO DETERMINE 
WHETHER A DATA STRUCTURE IS A NULL VALUE 

9002 



ir 



RECEIVING A RESPONSE TO THE QUERY FROM THE 
SECOND SYSTEM INDICATING WHETHER THE DATA STRUCTURE IS 

A NULL VALUE 

9004 



SENDING A REQUEST FOR THE DATA STRUCTURE FROM THE 
FIRST SYSTEM TO THE SECOND SYSTEM ONLY IF THE RESPONSE 
INDICATES THAT THE DATA STRUCTURE IS NOT A NULL VALUE 

9006 



RECEIVING THE DATA STRUCTURE FROM THE SECOND SYSTEM 

9008 



Fig. 90 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 Sheet 57 of 123 



US 6,636,242 B2 



^9200 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 58 of 123 US 6,636,242 B2 



9500 



BUILDING PAGES OF DATA SETS FROM DATA IN A 
DATABASE OF A SERVER 




9502 






RECEIVING A FIRST REQUEST FROM A CLIENT FOR THE DATA IN 
THE DATABASE OF THE SERVER 




9504 






SENDING A FIRST ONE OF THE PAGES OF THE DATA SETS TO THE 
CLIENT OVER A NETWORK IN RESPONSE TO THE FIRST REQUEST 




9506 




r 


RECEIVING A SECOND REQUEST FROM THE CLIENT FOR THE 
DATA IN THE DATABASE OF THE SERVER 




9508 






TRANSMiniNG A SECOND ONE OF THE PAGES OF THE DATA 
SETS TO THE aiENT OVER THE NETWORK IN RESPONSE TO THE 
SECOND REQUEST 

9510 



Fig. 95 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 59 of 123 US 6,636,242 B2 



Client 



9602 



1 



Client 



9602 



1 




( Get Customers 1 



9600 

4- 



9604 



Smith, Babbette 
Smith, Carl 
Smith, Cratph 
Smith, Deke 



( Gat Customers 1 



1. User pushes 'Get Customers' 
button 



2. Ul displays a list of customers 



Response time = Time 
between 1& 2 



Fig. 96 



Client 



9700 





1 Request for Data 1> 








< 


Data 






Networic 9M 




Fig. 97 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 60 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 61 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 62 of 123 us 6,636,242 B2 



10000 



CALUNG THE NAMING SERVICE FOR RECEIVING LOCATIONS 
OF THE GLOBAL ADDRESSABLE INTERFACES 

■ 10002 



GENERATING PROXIES BASED ON THE RECEIVED LOCATIONS OF 
THE GLOBAL ADDRESSABLE INTERFACES AS A RESULT 
OFTHECAaS 

10004 



RECEIVING THE PROXIES IN AN ALLOCATION QUEUE 



10006 



ALLOCATING THE PROXIES OF THE ALLOCATION QUEUE IN A 

PROXY POOL 

10006 



ALLOWING ACCESS TO THE PROXIES IN THE PROXY POOL FOR 
IDENTIFYING THE LOCATION OF ONE OF THE GLOBAL 
ADDRESSABLE INTERFACES IN RESPONSE TO A REQUEST 
RECEIVED FROM THE CLIENT 



Fig. 100 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 63 of 123 US 6,636,242 B2 



Trader Service 

dm 




Server 



Fig. 101 



Trader Service 




Server 



Fig. 102 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 64 of 123 US 6,636,242 B2 



A 



Proxy Handle 



n 



Allocated 
Proxies 



^10302 ^10304 




Allocation Thread 



Allocated Proxy 



1/ 



Proxy Pool 



10300 



Allocation 
Queue 



Unallocated Proxy 



^ Unallocated 
Proxies 



Fig. 103 




Aggregates 



Allocation Pool 

10406 



Creates 



Reference 











Pooled Proxy Handle 
1048 


Reference 


Pooled Proxy 

10402 


► 



Fig. 104 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 65 of 123 US 6,636,242 B2 



10500 



SENDING MESSAGES INCLUDING DATA BETWEEN A SENDING 
SYSTEM AND A RECEIVING SYSTEM 



10502 



ATTACHING META-DATATOTHE MESSAGES BEING SENT 
BETWEEN THE SENDING SYSTEM AND THE RECEIVING SYSTEM 



10504 



TRANSLATING THE DATA OF THE MESSAGES SENT FROM THE 
SENDING SYSTEM TO THE RECEIVING SYSTEM BASED ON THE 
METArDATA. WHEREIN THE META-DATA INCLUDES A FIRST 

SECTION IDENTIFYING A TITPE OF OBJECT ASSOCIATED WITH 
THE DATA AND A NUMBER OF AHRIBUTE DESCRIPTORS IN THE 

DATA AND A SECOND SECTION INCLUDING A SERIES OF THE 

AHRIBUTE DESCRIPTORS DEFINING ELEMENTS OF THE DATA 



10506 



Fig. 105 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 66 of 123 US 6,636,242 B2 



10602 



Object-based ^_^Jf^=^ 

(IIS) 
® ® 



.stream-on stream-off. ^^^^^^^ 

< System 
J9> (Strings) 



□□□□□□□□noDoaoc 



10600 



^ I streanvoff stream-on ^ 

< ^DDDaaDDaaQDaD| 



10700 



Object-based 
System 

Poodli 



Fig. 106 




Fig. 107 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 67 of 123 US 6,636,242 B2 



^10802 

Formatting Information 

(meta-data) ' 


Data 




^10800 


This record is 100 bytes long 
The name attribute ts a 10 byte string 
The sex attribute is a 4 byte Siring 
The age attribute is a 6 bytes Integer 
The status is a 10 byte String 
Etc. 


Fred 


Male 


21 


New 


• • • • 



30 40 44 50 100 



Fig. 108 



^10900 

Fomnalfing Information Data 
(Meta-data information) 




Header Attribute 
Section Descriptors 
Secton 



Fig. 109 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 68 of 123 US 6,636,242 B2 



11002 




11000 



Fig. 110 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 69 of 123 US 6,636,242 B2 



11100 



DEFINING A SHARED FORMAT ON INTERFACE CODE FOR A 
SENDING SYSTEM AND A RECEIVING SYSTEM 



1UQ2 



TRANSLATING A MESSAGE TO BE SENT FROM THE SENDING 
SYSTEM TO THE RECEIVING SYSTEM BASED ON THE SHARED 

FORMAT 



SENDING THE MESSAGE FROM THE SENDING SYSTEM 



11106 



RECEIVING THE MESSAGE BY THE RECEIVING SYSTEM 



11108 



TRANSLATING THE MESSAGE RECEIVED BY THE RECEIVING 
SYSTEM BASED ON THE SHARED FORMAT 



11110 



Fig. 111 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 70 of 123 US 6,636,242 B2 



1130(K^ 



Object-based 

System (q) 

(Objects) ^ 

® 



® 



® 



® 



11304 



11302 




Fig. 113 



11400 



z 



Object-based ^^^^Jf ^^^"'"^" ^"^""^^ ^^^ Non-Object 
(O^^^te) ^ }^aDoaannaaa^ ^^^) 



11404 



stream-on stream-off 



® (§) /-N 



strearrwrff stream-on 




Fig. 114 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 71 of 123 us 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 72 of 123 US 6,636,242 B2 



11600 



DETERMINING A TOTAL AMOUNT OF DATA REQUIRED FOR AN 
APPLICATION EXECUTED BY A CLIENT 



11602 



REQUESTING THE TOTAL AMOUNT OF DATA FROM A SERVER 
OVER A NETWORK IN A SINGLE CALL 



11604 



BUNDLING ALL OF THE DATA INTO A DATA STRUCTURE BY THE 
SERVER IN RESPONSE TO THE SINGLE CALL 



11606 



SENDING THE BUNDLED DATA STRUCTURE TO THE CLIENT OVER 

THE NETWORK 



CACHING THE DATA OF THE DATA STRUCTURE ON THE CLIENT 



11610 



USING THE CACHED DATA OF THE DATA STRUCTURE AS NEEDED 
DURING EXECUTION OF THE APPLICATION ON THE CLIENT 

11S12 



Fig. 116 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 73 of 123 US 6,636,242 B2 




Get Attribute 



Return Attribute 
Get Attribute 
Network 

Return Attribute 
Get Attribute 



Return Attribute 




Fig. 118 




Fig. 119 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 74 of 123 US 6,636,242 B2 



2000 



Client 



12002 



1. getCustomer("Jlmbo Jon e^ 2. getCustomef('Jimbo Jones')! 

I \^ - /r*t ■ -■ I I / 




7. Create Proxy to 
Jimbo Jones ) 



^Customer 
[Component} 
Proxy 



3, getCustomer 
("Jlmbo Jones') 




12000 




8. getCustomerAsStructureO 



aDataStructure 

- Jimbo Jones 
-33 Maple St 

- Gumee 
-IL 

-60030 



6. return (remote Object 
Reference) 



Network 



4. 'Jimbo Jones'data 



5. Create'Jimbo 
Jones"Object 



9imbo Jones Objec 
Methods: 
getCustomer.. 

Data: 
Jimbo Jones 
^3 Maple St. 



Database 



Fig. 120 




9. getCustomerAsStmctureO 



12. Return aDataStmcture 



Network 



11. Return aDataStructure 




Fig. 121 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct 21, 2003 sheet 75 of 123 US 6,636,242 B2 



Distributed 
Presentation 



Remote 
Presentation 



Distributed 
Function 



Remote Data 



Data 
Management 



Application 
Function 



Presentation 



Data 
Management 



Application 
Function 



Data 
Management 



Application 
Function 



Data 
Management 



Di$tribiAed 
Data Base 



Data 
Management 




Networlc 



Presentation 



Presentation 



IE 




Application 
Function 



Presentation 



Application 
Function 



Presentation 



Data 
Management 



Application 
Function 



Presentation 



Thin Client Application Functionality 

12200- 



Fat Client Application 
Packaging ana Distribution 



Fig. 122 



Application 
1240O 



Handheld 
Device 
12402 




Telecommunications- 
Device 
12406 



Desl^top 
PC 
12404 



Fig. 124 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 76 of 123 US 6,636,242 B2 

12300 



INTERFACING A SERVER AND A PRESENTATION INTERFACE OF A 

CLIENT 




12302 






RECEIVING REQUESTS FOR SERVICE FROM THE PRESENTATION 
INTERFACE OF THE CLIENT 




12304 






HANDLING AT LEAST A PORTION OF THE REQUESTS TO 
THE CLIENT 




12306 






FORWARDING ANOTHER PORTION OF THE REQUESTS TO THE 
SERVER FOR FURTHER HANDLING PURPOSES 




12308 






EFFECTING CHANGES IN THE PRESENTATION INTERFACE 




12310 



Fig. 123 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 77 of 123 US 6,636,242 B2 



interface 


0..n 1 


Activity 


1 0..f) 


Model 


125Q2 






13500 










0..n 








1..n 






Server 





Fig. 125 



creates 



interface 
12502 



forwards request 
to 



triggers changes 
in 



creates 



Activity 
125Q0 



manages 



forwards request 
to 





Fig. 126 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 78 of 123 US 6,636,242 B2 



validateO validateQ 
return isValid return isValid 




addButtonCiickedQ 
void 



Data Entry 



Name: 
SSN: 
Type: 



Status 



® Active 
® Inactive 



Networ1( 
Inventory 
Activity 



2706 



geUdenlifien 
return Itemlf 



8 



3.3 



Network 
Catalog 
Component 
Proxy 

12700 



:em(itemlD 



ctiecldtem(itemlD] 
return item DoesExist 

3.4 



3.2 



Network 
Item 
<aNetworkltem> 

12704 



1 



m 



m 



OK 



Network 
Component 
Proxy 



addltem 
(aNetworkltem) 
void 




Fig. 127 

12900 




unconstrained, 
needs fonnat 
validation 



constrained, 
doesn't need 
format vdidation 



Fig. 129 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 79 of 123 US 6,636,242 B2 



128000 



PROVIDING A PLURALITY OF USER INTERFACE WIDGETS 




12802 






PROVIDING A PLURALITY OF VALIDATION RULES WHICH 
GOVERN USE OF THE USER INTERFACE WIDGETS 




12804 




r 


ALLOWING A USER TO SELECT THE VALIDATION RULES TO 
ASSOCIATE WITH THE USER INTERFACE WIDGETS OF A RRST 

USER INTERFACE 

12806 




r 


AUTOMATICALLY ASSOCIATING THE VALIDATION RULES OF THE 
USER INTERFACE WIDGETS OF THE FIRST USER INTERFACE 
ACROSS A PLURALITY OF SEPARATE DIFFERENT 
USER INTERFACES 




12808 



Fig. 128 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 80 of 123 US 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 81 of 123 US 6,636,242 B2 





ValidataWldget 
<aWiclget> 

1320Q 




VaOdatlon 

Rule 
<aRule> 


valiidateRule(aRule} 
return passesvalidation 


— ► 

check(aWiciget) 
return passesVaiidation 



Fig. 132 



view 




View 

13402 




r 




t 

??? 


Search 
Activity 




Maintain 
Customer 
Activity 

13400 


^ 







Fig. 134 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 82 of 123 US 6,636,242 B2 



13300 



RECEIVING NOTIFICATION TH/>Cr A STARTUP EVENT OF AN 
ACTIVITY HAS OCCURRED 



13302 



RECEIVING A REFERENCE TO A RRST INSTANCE OF AN OBJECT 
CREATED BY THE STARTUP EVENT OF THE ACTIVITY 



13304 



DETERMINING A VIEW TO UUNCH IN RESPONSE TO THE RECEIPT 
OF THE NOTIRCATION AND THE REFERENCE, WHEREIN THE 
VIEW IS BASED ON PREDETERMINED CRITERIA 

1^ 



1 




ASSOCIATING THE VIEW WITH THE ACTIVITY 


13308 




f 


DISPLAYING THE VIEW 


13310 



Fig. 133 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 83 of 123 US 6,636,242 B2 





06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 84 of 123 US 6,636,242 B2 



13600 



RAISING A FIRST ASSERTION ASSERTING A PRE-CONDTION THAT 
MUST EVALUATE TO TRUE IF THE OPERATION IS SUCCESSFUL 

13602 







EXECUTING THE OPERATION 

13604 






RAISING A SECOND ASSERTION ASSERTING A POST-CONDITION 
THAT MUST EVALUATE TO TRUE IF THE OPERATION IS SUCCESSFUL 

13606 







OUTPUTTING AN ERROR MESSAGE UPON FAILURE OF AT LEAST 
ONE OF THE ASSERTIONS 

13606 



Fig. 136 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 85 of 123 US 6,636,242 B2 



13800 



MAINTAINING A COLLECTION OF OUTSTANDING SERVER OBJECTS 
13802 

i 



CREATING A LIST OF CONTEXTS FOR EACH OF THE OUTSTANDING 

SERVER OBJECTS 

13804 



ADDING TO THE LIST A COMPILATION OF CLIENTS WHO ARE 
INTERESTED IN EACH OF THE OUTSTANDING SERVER OBJECTS 



13806 

i . 



RECORDING ON THE LIST A DURATION OF TIME SINCE THE CLIENTS 
INVOKED A METHOD ACCESSING EACH OF THE CONTEXTS OF THE 
OUTSTANDING SERVER OBJECTS 

13808 



EXAMINING THE LIST AT PREDETERMINED INTEI^ALS FOR 
DETERMINING WHETHER A PREDETERMINED AMOUNT OF TIME HAS 
PASSED SINCE EACH OF THE OBJECTS HAS BEEN ACCESSED 

13810 



SELECTING CONTEXTS THAT H/VE NOT BEEN ACCESSED IN THE 
PREDETERMINED AMOUNT OF TIME 

13812 



SENDING INFORMATION TO THE CLIENTS IDENTIFYING THE 
CONTEXTS THAT HAVE NOT BEEN ACCESSED IN THE 
PREDETERMINED AMOUNT OF TIME 

Mil 



Fig. 138 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 86 of 123 US 6,636,242 B2 




Fig. 139 




A, Client 1 300$ 

A, Client 2 425s 

B, Client 1.440s 

B, Client 2,300s 

C, Client 2, 2s 



Fig. 140 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 87 of 123 US 6,636,242 B2 











Server 


aient 1 


Interested 


Network 




14102 

G0 




Interested 
in B? 
















Client 2 








\ReaperJ 










14100 



Register still 
interested in B 



B, Client 2,0s 

C. Client 2. 3s 



Fig. 141 



Exception '-^ 
14302 / 




/ Exception 
B 



N, ^ ^ 



^ — - 



Exception ;- 
C 



s. ^ — — ^ 



Handling 
Logic-B 



Handling 
Logic-C 



Fig. 143 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 88 of 123 US 6,636,242 B2 



14200 

J 

DETERMINING NAMING CONVENTIONS OF EXCEPTIONS 

14202 



ADDING AT LEAST ONE OF A PREFIX AND A SUFFIX TO EACH 
EXCEPTION INTERFACE NAME FOR INDICATING THAT THE 
EXCEPTION INTERFACE IS AN EXCEPTION u 



INDICATING WHERE AN EXCEPTION ERROR OCCURRED 

14206 



DETERMINING WHAT CAUSED THE EXCEPTION ERROR 



14208 



PROVIDING CONTEXT AS TO WHAT WAS HAPPENING WHEN THE 
EXCEPTION ERROR OCCURRED 

14210 



ALLOWING STREAMING OF THE EXCEPTION TO A COMMON 



INTERFACE 



J4212 



OUTPUniNG AN ERROR MESSAGE INDICATING THAT AN EXCEPTION 
ERROR HAS OCCURRED 



Fig. 142 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 89 of 123 US 6,636,242 B2 



/ Base Excp \. 






Handling 




Logic B 







/ Exception 
-, 14400 /'' 



/ Exception '-^ 
B 

\_ 144Q2 /' 



Exception 

: c ; 

\_ 14404 



^ — ^ ** — ^ 



Fig. 144 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 90 of 123 us 6,636,242 B2 



14500 
J 



PROVIDING AN EXCEPTION RESPONSE TABLE 



14502 



RECORDING AN EXCEPTION IN THE EXCEPTION RESPONSE 

TABLE 

14504 



ENTERING THE CONTEXT OF THE EXCEPTION IN THE 
EXCEPTION RESPONSE TABLE 



14506 



USTING A RESPONSE FOR THE EXCEPTION IN THE EXCEPTION 
RESPONSE TABLE 

14508 



OUTPUTTING THE RESPONSE UPON THE EXCEPTION OCCURRING 

IN THE CONTEXT 

14510 



Fig. 145 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 91 of 123 US 6,636,242 B2 



14600 



ORGANIZING EXCEPTIONS INTO HIERARCHIES IN A POLYMORPHIC 

EXCEPTION HANDLER 
14602 



I 



CATCHING A ROOT OF ONE OF THE HIERARCHIES IN WHICH AN 
EXCEPTION OCCURS 

14604 



I 



INSTRUCTING THE EXCEPTION TO RETHROW ITSELF 



14606 



CATCHING THE RETHROWN EXCEPTION 



14608 



IDENTIFYING THE RETHROWN EXCEPTION 



14610 



DETERMINING A TYPE OF THE RETHROWN EXCEPTION 



OUTPUniNG A MESSAGE INDICATING THE TYPE OF THE RETHROWN 

EXCEPTION 

14614 



Fig. 146 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 92 of 123 US 6,636,242 B2 





06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 Sheet 93 of 123 US 6,636,242 B2 



14900 



RECEIVING INCOMING REQUESTS 


14902 




STORING THE REQUESTS 


14904 




DETERMINING AN AVAILABILITY OF SERVER COMPONENTS 


14906 


i 


COMPILING A LISTING OF AVAILABLE SERVER COMPONENTS 


14908 



DETERMINING WHICH SERVER COMPONENT ON THE LISTING OF 
AVAILABLE SERVER COMPONENTS IS MOST APPROPRIATE TO 
RECEIVE A PARTICULAR REQUEST 

14910 



SENDING EACH PARTICULAR REQUEST TO THE SELECTED 
SERVER COMPONENT DETERMINED TO BE MOST APPROPRIATE 
TO RECEIVE THE PARTICULAR REQUEST 

mi 



Fig. 149 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 94 of 123 us 6,636,242 B2 




06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 95 of 123 US 6,636,242 B2 



PROVIDING INTERCONNECTIONS BETWEEN DISTRIBUTED 
COMPONENTS EACH HAVING NESTED SERVICE INVOCATIONS 

15202 



15200 



1 



IDENTIFYING A USER 


15204 




ASSOCIATING THE USER WITH RaES 




15206 



CREATING A USER CONTEXT INST^NCE UPON SUCCESSFUL 
IDENTIFICATION OF THE USER. WHEREIN THE USER CONTEXT 
INSTANCE INCLUDES INFORMAHON ABOUT THE USER 

INCLUDING THE ROLES 15203 



I 



RECBVING A REQUEST FROM THE USER TO INVOKE A SERVICE ON 
A COMPONENT, WHEREIN THE COMPONENT INVOKES AN 
ADDITIONAL SERVICE OF ANOTHER COMPONENT 

ISlfl 



I 



QUERYING THE USER CONTEXT FOR THE INFORMATION ABOUT THE 

USER 

Ig^ 



COMPARING THE USER INFORMATION WITH AN ACCESS CONTROL 
LIST FOR VERIFYING THAT THE USER HAS 

ACCESS TO THE COMPONENT 
. . 15214 

1 



COMPARING THE USER INFORMATION WITH AN ACCESS CONTROL 
LIST FOR VERIFYING THAT THE USER HAS ACCESS TO THE 

ADDITIONAL SERVICE OF THE OTHER COMPONENT ^ 



Fig. 152 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 96 of 123 US 6,636,242 B2 



addStock(aStockName. 
numberOfShares) 

return success 



Portfolio 
15300 



deductFromAccount(anAmount} 
return amountCleared 



Rnance 
15304 



ge^ockPrice(aStockName) 
retumaPrice 




Fig. 153 



manages 




assodates User 
Context's with 





Fig. 154 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 97 of 123 US 6,636,242 B2 



15500 



PROVIDING A DATABASE 



15502 



DETERMINING A CONVERSION PROCESS FOR CONVERTING AN 
OBJECT ATTRIBUTE TO AND FROM A DATABASE VALUE 

15504 



ENCAPSULATING THE CONVERSION PROCESS IN AN ATTRIBUTE 

CONVERTER 



15506 



DIRECTING A FIRST OBJECT ATTRIBUTE TO THE ATTRIBUTE 
CONVERTER FOR CONVERSION TO A FIRST DATABASE VALUE 



15508 



DIRECTING A SECOND DATABASE VALUE TO THE ATTRIBUTE 
CONVERTER FOR CONVERSION TO A SECOND OBJECT 
AHRIBUTE 

15510 



Fig. 155 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent OO. 21, 2003 Shtet 98 of 123 us 6,636,242 B2 




Fig. 156 




Fig. 157 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 Sheet 99 of 123 



US 6,636,242 B2 



15800 



PROVIDING A DATA RETRIEVAL MECHANISM FOR RETRIEVING 
DATA FROM A DATABASE. WHEREIN TWE DATA RETRIEVAL 
MECHANISM WRITES DATA TO THE DATABASE 


15802 






ENCAPSULATING THE DATA RETRIEVAL MECHANISM IN A DATA 

HANDLER 


15804 






RECEIVING A REQUEST FROM A DOMAIN OBJECT FOR A 
RETRIEVAL OF A PORTION OF THE DATA IN THE DATABASE 


15806 






UTILIZING THE DATA RETRIEVAL MECHANISM TO RETRIEVE THE 
PORTION OF THE DATA FROM THE DATABASE 

15808 






PASSING THE PORTION OF THE DATA THROUGH THE DATA 
HANDLER TO THE DOMAIN OBJECT 


15810 



Fig. 158 



06/17/2004, EAST Version: 1,4.1 



U.S. Patent 



Oct. 21, 2003 



Sheet 100 of 123 



US 6,636,242 B2 




Fig. 159 



Persist 




16002 




inherits 



Access 



Database 
160QQ 




Fig. 160 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 101 of 123 US 6,636,242 B2 



CO 



CO 



Li- 




o 




a> 

O) 
CO 

c 
ca 



CO 















3 










CL 







(/> o 
T3 -u 



§ a> cTj 
a. == o 




06/17/2004, EAST Version: 1,4.1 



U.S. Patent Oct. 21, 2003 Sheet 102 of 123 US 6,636,242 B2 



16300 



RETRIEVING DATA ABOUT A USER 




16302 






PACKAGING THE DATA INTO A CROSS-FUNCTIONAL DATA OBJECT 




16304 







RETRIEVING A REQUEST FOR DATA FROM ONE OF A PLURITY 
OF BUSINESS OBJECTS 

16306 



DIRECTING THE BUSINESS OBJECT TO THE DATA OBJECT SUCH 

THAT THE BUSINESS OBJECT RETRIEVES THE ENTIRE DATA 
OBJECI WHEREIN THE BUSINESS OBJECT SELECTS THE DATA 
FROM THE DATA OBJECT 

16308 



Fig. 163 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 103 of 123 us 6,636,242 B2 



struct AccountPaymentData 
{ 

char accountlD[24] 
customerlD[24] 

Money serviceCharges, 
balanceDue, 
amountPaid; 

Date paymentdate 

int creditCardNum, 
checkNum; 

); 



Fig. 164 



Account Payment 



Account ID 


1 101 1 


Customer ID 


1 ABCD 1 


Service charges 


1 $10.93 1 


Balance Due 


1 $27.11 


Amount Paid 


$27.11 


Date 


7/2/95 


©Credit Card # 


i 3892 


oCheck# 




Save 


Cancel 



(c= Account Payment 


Account ID 


1 101 


Customer ID 


1 ABCD 


Service charges 


$10.93 1 


Balance Due 


1 $27.11 


Amount Paid 


1 $27.11 


Date 


1 7/2«5 1 


©Credit Card # 


1 3892 


0 Check* 


1 


1 Save 1 


Cancel 




Fig. 165 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 104 of 123 US 6,636,242 B2 



16600 



PROVIDING A BUSINESS OBJECT AND A PLURALITY OF 
REMAINING OBJECTS ON A PERSISTENT STORE 




16602 






RECEIVING A REQUEST FOR THE BUSINESS OBJECT 




16604 






ESTABLISHING WHICH OF THE REMAINING OBJECTS ARE 
RELATED TO THE BUSINESS OBJECT 




16606 






RETRIEVING THE RELATED OBJECTS AND THE BUSINESS OBJECT 
FROM THE PERSISTCNT STORE IN ONE OPERATION 




16608 






DEfHRMINING HOW THE RETRIEVED RELATED OBJECTS RELATE 
TO THE BUSINESS OBJECT AND EACH OTHER 




16610 






INSTANTIATING A GRAPH OF RELATIONSHIPS OF THE BUSINESS 
AND RELATED OBJECTS IN MEMORY 




16612 



Fig. 166 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 105 of 123 US 6,636,242 B2 



16700 




aient 



Fig. 167 

Server 



Decla re Fetch Spec 

Fetch Household using fetch spec to fetch the other related objects ^ 



Fill In relationships 

' Household Hobbyist 

getHousehold ^1 



1680 



Repeat 
for each 
hobbyist 



Hobby 



Interest 



Fig. 168 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 106 of 123 US 6,636,242 B2 



Client 



Household 



getHousehold 



Server 



Retrieve Household from a data store 



Hobbyist 



getHobbyists ^ Retrieve Hobbyists from a data store 



Repeat 
for each 
hobbyist 




Retrieve Hobbies 
from a data store 



Interest 



Retrieve Interests 
from a data store 



Fig. 169 





■ Sded * from Customer 

■ where custID = 123 


^ 

Return 

customer 123 


. 3. Return 


123 

4. Insert customer 123 
•9 1 in the cache 


^ — — 

5. Object 


2. Check for customer 123 
in cache 

^ 1 


Return 

customer 123 





Fig. 172 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 21, 2003 Sheet 107 of 123 US 6,636,242 B2 



17000 



PROVIDING A BUSINESS OBJECT 

17002 






STORING AN INSTANCE OF AN ASSXIATED OBJECT ON A 
DATABASE 






DETERMINING AN ASSOCIATION OF THE BUSINESS OBJECT WITH 
THE INSTANCE OF THE ASSOCIATED OBJECT 




17006 







GENERATING AN OBJECT IDENTIFIER CONTAINING INFORMATION 

INCLUDING THE DETERMINATION ASSOCIATION WHICH IS 
NECESSARY TO RETRIEVE THE INSTANCE OF THE ASSOCIATED 
OBJECT FROM THE DATABASE 



1 

LOADING THE OBJECT IDENTIFIER WHEN THE BUSINESS 
OBJECT STARTS 



DETERMINING A LOCATION OF TH 
OBJECT ON THE DATABASE F 


r 

E INSTANCE OF THE ASSOCIATED 
ROM THE OBJECT IDENTIFIER 

17P12 






RETRIEVING THE INSTANCE OF THE ASSOCIATED OBJECT FROM 

THE DATABASE 

17014 



Fig. 170 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 108 of 123 US 6,636,242 B2 



17100 



RETRIEVING AN OBJECT FROM A DATA STORE 



CACHING AN OBJECT 



17104 



ASSIGNING A UNIQUE OBJECT IDENTIFIER TO THE OBJECT 



17106 



MAPPING THE OBJECT IDENTIFIER TO A REPRESENTATION OF THE 
OBJECT IN A DICTIONARY 

11108 



RECEIVING A REQUEST FOR A REFERENCE TO THE OBJECT 



17110 



RETRIEVING THE OBJECT IDENTIFIER OF THE OBJECT FROM THE 

DICTIONARY 



17112 



ASSOCIATING THE REQUESTED REFERENCE WITH THE 
REPRESENTATION OF THE OBJECT STORED IN THE DICTIONARY 

17114 



Fig. 171 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 109 of 123 



US 6,636,242 B2 



17300 



ACCESSING A PERSISTENT OBJECT BEING DEVELOPED 



17322 





r 


DETACHING A STATE OF THE PERSISTENT OBJECT INTO A 
SEPARATE STATE CLASS. WHEREIN THE STATE CLASS SERVES 
AS A CONTRACT BETWEEN A LOGIC DEVELOPMENT TEAM 
AND A DATA ACCESS DEVELOPMENT TEAM 

17304 






LIMITING LOGIC OEVELOPMEN" 
TEAMTODEVELOPI 


r BY THE LOGIC DEVELOPMENT 
NO BUSINESS LOGIC 

17306 



RESTRICTING DATA ACCESS DEVELOPMENT BY THE DATA 
ACCESS DEVELOPMENT TEAM TO PROVIDING DATA CREATION. 
RETRIEVAL, UPDATING. AND DELETION CAPABILITIES 

123Q8 



Fig. 173 



06/17/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 21, 2003 sheet 110 of 123 US 6,636,242 B2 



17400 



PROVIDING AN OBJECT WITH AT LEAST ONE MISSING ATTRIBUTE 



17402 



RECEIVING A REQUEST FROM AN APPUCATION FOR THE OBJECT 



17404 



ALLOWING ACCESS TO THE ATTRIBUTES OF THE OBJECT BY THE 

APPLICATION 



PROVIDING A WARNING UPON AN ATTEMPT TO ACCESS THE 
AHRIBUTE OF THE OBJECT THAT IS MISSING 



17408 



Fig. 174 
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AccounI 




17506 



Fig. 175 




17600- 



struct accountPaymentData 

char accountID 
customerlO 

money serviceCharges, 
balanceDue, 
amountPaid; 

Date paymentDate; 

int creditCardNum, 
. checkNum; 

' 1^ - 



Transaction 
Processor 
System 



Fig. 176 
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Data 
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17900 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY 
FOR A TRANSACTION 



BATCHING LOGICALLY-RELATED REQUESTS RECEIVED FROM THE 
BUSINESS OBJECTS INTO A SINGLE NETWORK MESSAGE. WHEREIN 



ONE OF THE REQUESTS IS A PARENT REQUEST 



17904 



RECEIVING A REGISTER THAT AT LEAST ONE OF THE REQUESTS IS 
DEPENDENT UPON THE RESPONSE DATA FROM THE 

PARENT REQUEST JI906 



SENDING THE NETWORK MESSAGE ACROSS A NETWORK 



17908 



UNBUNDLING THE REQUESTS FROM THE NETWORK MESSAGE 

12910 



RECEIVING A RESPONSE TO THE PARENT REQUEST 



12m 



DIRECTING DATA FROM THE RESPONSE TO THE PARENT 
REQUEST TO THE DEPENDENT REQUEST 



12S14 



RECEIVING A RESPONSE TO THE DEPENDENT REQUEST BASED ON 
THE RECEIVED DATA FROM THE RESPONSE TO THE PARENT 

REQUEST ^^g^g 



Fig. 179 
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1. retrieve f Account 
Id 101 



2. retrieve ^ /Customer) 




Request^ 
Batcher 

18000 



4. Send Transaction: 
a Account 101 

b. Customer??? 

c. Monthly 6111274 



3. retrieve 




Fig. 180 



4. depend on 




1. retrieve ^/ Account 
Id 101 



2. retrieve^ /Customer 
Id?? 



4. Send Transaction: 
a. Account 101 
and dependent Customer 
Request ^ c. Monthly Bill 274 
Batcher 



3. retrieve 



Fig. 181 
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18200 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY FOR 

A TRANSACTION 

18202 



MANAGING THE GROUP OF BUSINESS OBJECTS NECESSARY TO 
THE TRANSACTION IN A LOGICAL UNIT OF WORK 

18204 



CREATING A RECEIVER WHICH COMMUNICATES WITH THE 
BUSINESS OBJECTS IN THE LOGICAL UNIT OF WORK 



18206 



RECEIVING A MESSAGE FOR THE BUSINESS OBJECTS IN THE 
LOGICAL UNIT OF WORK 



18208 



DIRECTING THE MESSAGE TO THE RECEIVER. WHEREIN THE 
RECEIVER FORWARDS THE MESSAGE TO EACH OF THE 
BUSINESS OBJECTS IN THE LOGICAL UNIT OF WORK 

18210 



Fig. 182 
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18500 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY FOR 

A TRANSACTION 

18502 



MANAGING THE GROUP OF BUSINESS OBJECTS NECESSARY TO 
THE TRANSACTION IN A LOGICAL UNIT OF WORK 

18504 



GROUPING LOGICALLY-RELATED REQUESTS RECEIVED FROM 
THE LOGICAL UNIT OF WORK INTO A SINGLE NETWORK MESSAGE 

18506 



STORING THE MESSAGE 



18508 



SENDING THE MESSAGE UPON RECEIVING AN ORDER TO SEND 

THE MESSAGE 

18510 



Fig. 185 
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Fig. 187 
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18800 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY 
FOR A TRANSACTION 



18802 



GROUPING LOGICALLY-RELATED REQUESTS RECEIVED FROM THE 
BUSINESS OBJECTS ^^q^ 



OBTAINING AT LEAST ONE OF SORTING RULES AND SORT WEIGHTS 



18806 



SORTING THE REQUESTS IN THE MESSAGE AND PLACING THEM IN A 
SPECIRC ORDER DETERMINED FROM THE ONE OF THE SORTING 
RULES AND THE SORT WEIGHTS 

18808 



T 



BATCHING THE SORTED REQUESTS INTO A SINGLE MESSAGE 



SENDING THE MESSAGE TO A DATA SERVER 



mi 



UNBUNDLING THE REQUESTS FROM THE MESSAGE IN THE SPECIFIC 

ORDER 

18814 



Fig. 188 
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3. update 




Request 
Batcher 



4. Send Transaction! 

a. Account 

b. Customer 

c. Monthly Bill 



Fig. 189 



3. update 




5. Send Transaction: 

a. Account 

b. Customer 

c. Monthly Bill 



Request 
Batcher 



4. sort 
19000 




Fig. 190 
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19100 



PROVIDING MULTIPLE LOGICAL UNITS OF WORK OPERATING 
CONCURRENTLY, WHEREIN EACH OF THE LOGICAL UNITS OF 
WORK MANIPULATE AT LEAST ONE COMMON BUSINESS OBJECT 



CREATING A COPY OF THE COMMON BUSINESS OBJECT FOR 
EACH OF THE LOGICAL UNITS OF WORK SUCH THAT THE COPY 
OF THE BUSINESS OBJECT FOR ONE LOGICAL UNIT OF WORK 
BECOMES A SEPARATE INSTANCE FROM THE COPY OF THE 
BUSINESS OBJECT FOR ANOTHER LOGICAL UNIT OF WORK. 
WHEREIN EACH COPY OF THE BUSINESS OBJECT KNOWS THE 
CONTEXT OF THAT COPY OF THE BUSINESS OBJECT IN RELATION 
TO THE ASSOCIATED LOGICAL UNIT OF WORK 



RECEIVING A REQUEST TO MAKE CHANGES TO A COPY OF THE 
BUSINESS OBJECT OF ONE OF THE LOGICAL UNITS OF WORK 
AND CHANGING THAT COPY OF THE BUSINESS OBJECT, 
WHEREIN THE OTHER COPIES OF TH BUSINESS OBJECT 



ARE NOT CHANGED 



19106 







VERIFYING THAT ONLY ONE COPY OF THE BUSINESS OBJECT 


HAS BEEN CHANGED 




19108 






UPDATING THE COMMON BUSINESS OBJECT BASED ON THE 


CHANGE TO THE COPY OF THE BUSINESS OBJECT 




19110 



Fig. 191 
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^ Account Payment 



Account ID 


1 101 1 


Customer ID 


UbcdI 


Service Charges 


hmm 


Balance Due 




Amount Paid 


|$27.11| 


Date 


17/2/951 


©Credit Card # 


immW 


O Check* 




i Save 1 


|Cancei|\ 



Account Services 



Account ID 
Customer ID 



fABCP] 



Sen/Ice 



Cost 



XCaliWeitina 


$3.00 




Foiwarding 


$2.00 




X 3-Way 
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Caller ID 
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X Phone Rental 
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Fig. 192 
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j[c=aj Account Payment 



Account ID 
Customer ID 



lABCDI 



Service Charges 
Balance Due 
Amount Paid 
Date 



rfj2}% 



©Credit Card # 
O Check # 



|c3| Account Setvioes 



Account ID 


1 101 1 


Customer ID 


lABCOl 


Senrice 


Cost 


X Canwaltlna 


$3.00 




Forwarding 


$2.00 




X ^Wav 
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CaUerlD 
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|ca| Account Payment" 
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VffiW CONFIGURER IN A PRESENTATION 
SERVICES PATTERNS ENVIRONMENT 

CROSS REFERENCE TO RELATED 
APPUCAnONS 

lliis application is related to United States Patent Appli- 
cations entitled ASYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR A DEVELOPMENT ARCHITEC- 
TURE FRAMEWORK Ser. No. 09/387,747 and A 
SYSTEM, METHOD AND ARTICLE OF MANUFAC- 
TURE FOR MAINTENANCE AND ADMINISTRAHON 
IN AN E-COMMERCE APPLICAnON FRAMEWORK 
Ser. No. 09/387,318, both of which are filed concurrently 
herewith and which are incorporated by reference in their 
entirety, 

FIELD OF THE INVENTION 

The present invention relates to configuring views and 
more particularly to assigning views to an activity. 

BACKGROUND OF THE INVENTION 

An important use of computers is the transfer of infor- 
mation over a network. Currently, the largest computer 
network in existence is the Internet. The Internet is a 
worldwide interconnection of computer networks that com- 
municate using a common protocol. Millions of computers, 
from low end personal computers to high-end super com- 
puters are coupled to the Internet. 

The Internet grew out of work funded in the 1960s by the 
U.S. Defense Department's Advanced Research Projects 
Agency. For a long time, Internet was used by researchers in 
universities and national laboratories to share information. 
As the existence of the Internet became more widely known, 
many users outside of the academic/research community 
(e.g., employees of large corporations) started to use Internet 
to carry electronic mail. 

In 1989, a new type of information system known as the 
World-Wide-Web ("the Web'") was introduced to the Inter- 
net. Early development of the Web took place at CERN, the 
European Particle Physics Laboratory. The Web is a wide- 
area hypermedia information retrieval system aimed to give 
wide access to a large universe of documents. At that time, 
the Web was known to and used by the academic/research 
community only. There was no easily available tool which 
allows a technically untrained person to access the Web. 

In 1993, researchers at the National Center for Supercom- 
puting Applications (NCSA) released a Web browser called 
"Mosaic** that implemented a graphical user interface (GUI). 
Mosaic's graphical user interface was simple to learn yet 
powerful. The Mosaic browser allows a user to retrieve 
documents from the World-Wide-Web using simple point- 
and-click commands. Because the user does not have to be 
technically trained and the browser is pleasant to use, it has 
the potential of opening up the Internet to the masses. 

The architecture of the Web follows a conventional client- 
server model. The terms "client" and "server" are used to 
refer to a computer's general role as a requester of data (the 
client) or provider of data (the server). Under the Web 
environment, Web browsers reside in clients and Web docu- 
ments reside in servers. Web clients and Web servers com- 
municate using a protocol called "Hyperlbxt Transfer Pro- 
tocol" (HTTP). Abrowser opens a connection to a server and 
initiates a request for a document. The server delivers the 
requested document, typically in the form of a text document 
coded in a standard Hypertext Markup Language (HTML) 
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format, and when the connection is closed in the above 
interaction, the server serves a passive role, i.e., it accepts 
commands from the client and caimot request the cUent to 
perform any action. 

5 The communication model under the conventional Web 
environment provides a very limited level of interaction 
between clients and servers. In many systems, increasing the 
level of interaction between components in the systems 
often makes the systems more robust, but increasing the 

10 interaction increases the complexity of the interaction and 
typically slows the rate of the interaction. Thus, the con- 
ventional Web environment provides less complex, faster 
interactions because of the Web^s level of interaction 
between clients and servers. 

15 

SUMMARY OF THE INVENTION 

A system, method and article of manufacture are provided 
for assigning a view to an activity. Notification is received 

^ that a startup event of an activity has occurred. A reference 
to a first instance of an object created by the startup event of 
the activity is also received. A view to launch is determined 
in response to the receipt of the notification and the refer- 
ence. The view is based on predetermined criteria. The view 

^ is associated with the activity and displayed. 

In an aspect of the present invention, the predetermined 
criteria may include user preferences, an experience level of 
a user, security profiles, and/or workflow settings. In another 
aspect of the present invention, the activity may be allowed 

30 to run without a corresponding view. In a further aspect of 
the present invention, the activity may operate on a machine 
separate from a machine of an end user. 

In one embodiment of the present invention, a request 
may be sent to be notified when a new instance of an object 

35 is created. In another embodiment of the present invention, 
a configuration file may be read for obtaining configuration 
information. 

BRIEF DESCRIPTION OF THE DRAWINGS 

40 The invention will be better understood when consider- 
ation is given to the following detailed description thereof. 
Such description makes reference to the annexed drawings 
wherein: 

FIG. 1 is a schematic diagram of a hardware implemen- 
tation of one embodiment of the present invention; 

FIG. 2 is a flow diagram illustrating a high level overview 
of an architecture; 

FIG. 3 shows the dependencies of three architecture 
50 firameworks; 

FIG. 4 illustrates a delivery vehicle matrix; 

FIG 5 iUustrates a Delivery Vehicle Cube; 

FIG. 6 is a flow diagram depicting considerations to be 
taken into consideration when identifying the core technolo- 
gies to be used in an architecture; 

FIG. 7 is a chart that can be utilized to determine whether 
to use Netoentric technology; 

FIG. 8 is a chart that can be utilized to determine whether 
to use Client Server technology; 

FIG. 9 is a chart that can be utilized to determine whether 
to use Host technology; 

FIG. 10 Ulustrates the services of a Netcentric Architec- 
ture Framework in accordance with one embodiment of the 
65 present invention; 

FIG. 11 is a detailed diagram of some of the components 
of the Netcentric Architecture Framework found in FIG. 10; 
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FIG. 12 is a detailed diagram of other components of the FIG. 44 shows a high level picture of application com- 

Netccntric Architecture Framework fotmd in FIG. 10; poncnt interaction for an Order Entry system; 

FIG. 13 illustrates several components of the Presentation FIG. 45 illustrates a traditional organization structure 

area of the Netcentric Architecture Framework; including an activities component, a credit/collections 

HG. 14 illustrates several components of the Information ^ component, a billing component, and a finance component; 

Services of the present invention; FIG. 46 provides an illustration of a horizontal organiza- 

FIG. 15 depicts the four major categories of functionality tion model; 

that the Network services provided by the Communications FIG. 47 illustrates a workcell organization approach 

Services are grouped into; including an activities component, a credit/coUections 

FIG. 16 illustrates File Sharing services; component, a billing component, and a finance component; 

FIG. 17 depicts Message Passing services; FIG. 48 illustrates the Enterprise Information Architecture 

FIG. 18 depicts Message Queuing services; (EIA) model; 

FIG. 19 illustrates Publish and Subscribe services; FIG. 49 illustrates a V-model of \fcrification, Validation, 

FIG. 20 deplete Streaming, in which a real-time data 15 and Testing; 

stream is transferred; FIG. 50 portrays of a development architecture with a 

FIG. 21 illustrates CORBA-based Object Messaging; seamless integration of tools which can be plugged in for the 

FIG. 22 illustrates COM Messaging; capture and communication of particular deUverables; 

FIG. 23 represents CTl Messaging; * architecture with the compro- 

FIG. 24 illustrates various components of the Communi- "^^^^^ '"^^'^ ^^^^y'^ component constniction environ- 

cation Fabric of the present invention; ment, 

HG. 25 illustrates the two categories of the Physical ^2 illustrates a business process to object mapping; 

^f edia; I^IG. 53 is a diagram which illustrates a graph of resilience 

FIG. 26 illustrates several of the components of the 25 ^ change; 

Transaction areas of the Netcentric Architecture Framework; FIG. 54 illustrates a flowchart for a method for providing 

FIG. 27 illustrates various componente of the Environ- an abstraction factory pattern in accordance with an embodi- 

mental Services of the Netcentric Architecture Framework; ^^nt of the present invention; 

FIG. 28 illustrates the Base Services of the Netcentric ^IG. 55 iUustrates a flowchart for a method for represent- 
Architecture Framework; "^^ i^g ^ plurality of batch jobs of a system each with a tmique 

FIG. 29 shows the major components of the reporting "r^^^ ^ accordance with an embodiment of the present 

application framework; mvenuon; 

RG. 30 iUustrates an example of how a custom report illiistrates a class diagram of the batch job 
architecture relates to a workstation platform technology 35 hierarchy; 

architecture; FIG. 57 illustrates an object interaction graph of a pos- 

HG. 31 describes the relationships between the major ^^^^ implementation of the class diagram of FIG. 56; 

components of the report process and the report writer FIG. 58 illustrates a flowchart for a method for controlling 

process; access to data of a business object via an attribute dictionary 

FIG. 32 shows the module hierarchy for the custom report 40 ^ accordance with an embodiment of the present invention; 

process; FIG. 59 illustrates a flowchart for a method for structuring 

FIG. 33 depicts the various components of the Business batch activities for simplified reconfiguration in accordance 

Logic portion of the Netcentric Architecture Framework; with an embodiment of the present invention; 

FIG. 34 illustrates a relationship between major themes FIG. 60 illustrates the manner in which the AttributeDic- 
that impact aspects of software development and manage- 45 tionaryClient is the facade which delegates to the Attribute - 

ment; Dictionary; 

FIG. 35 illustrates how components arc viewed from FIG. 61 depicts the use of the containsKey( ) method on 

different perspectives; the HashMap to ensure that the value will exist before the 

FIG. 36 shows a relationship between business compo- get( ) method is used; 

nents and partitioned business components; FIG. 62 illustrates a method that dictates that any 

FIG. 37 shows how a Billing Business Component may nulIPointcrException that is thrown would be caught and 

create an invoice; rethrown as the more user-friendly exception in the attribute 

FIG. 38 illustrates the relationship between the spectrum dictionary pattern environment; 

of Business Components and the types of Partitioned Busi- FIG. 63 iUustrates the Get the Attribute Names method in 

ness Components; the attribute dictionary pattern environment; 

FIG. 39 illustrates the flow of workflow, dialog flow, FIG. 64 iUustrates a flowchart for a method for managing 

and/or user interface designs to a User Interface Component; constants in a computer program in accordance with an 

FIG. 40 is a diagram of an Application Model which embodiment of the present invention; 
illustrates how the different types of Partitioned Business ^ FIG. 65 iUustrates a flowchart for a method for providing 

Components might interact with each other; a fixed format stream-based communication system in 

FIG. 41 illustrates what makes up a Partitioned Business accordance with an embodiment of the present invention; 

Component; FIG. 66 illustrates two systems communicating via a 

FIG, 42 iUustrates the role of patterns and frameworks; stream-based communication and using a common generic 

FIG, 43 iUustrates this Business Component Identifying 65 format to relay the meta-data information; 

Methodology including both Planning and Delivering FIG. 67 fllustrates an example of a Fixed Format message 

stages; associated with the fixed format stream patterns; 
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FIG. 68 depicts the complete Fixed Format Stream pattern 
associated with the fixed format stream patterns; 

FIG. 69 illustrates fixed format contracts containing meta- 
data information for translating structured data onto and off 
of a stream; 5 

FIG. 70 illustrates a Customer object in an object -based 
system streaming itself into a stream, the stream being sent 
to a Don-object system, this stream being read and the data 
inserted into a relational database; 

FIG. 71 illustrates a flowchart for a method for delivering 
service via a globally addressable interface in accordance 
with an embodiment of the present invention; 

FIG. 72 depicts a client that is iinable to find the services 
provided by a server via a network; 

FIG. 73 illustrates the grouping of services using inter- 
faces; 

FIG. 74 illustrates a customer server publicly announcing 
its interfaces; 

FIG. 75 illustrates a method including the registering and 20 
then locating of a globally addressable interface; 

FIG. 76 illustrates the present invention using a method 
wherein a globally addressable interface is used to obtain 
data from a server; 

FIG. 77 illustrates a flowchart for a method for affording ^ 
access to a legacy system in accordance to an embodiment 
of the present invention; 

FIG. 78 depicts the communication difficulties associated 
with Legacy Systems attempting to communicate with a 
cUent via a component integration architecture; 

FIG. 79 fllustrates homogenous interfaces from compo- 
nents which rectify the problems with Legacy Systems 
attempting to communicate with a client via a component 
integration architecture; 

FIG. 80 shows how a Legacy Component is integrated 
into a component-based model; 

FIG. 81 illustrates Legacy Wrapper Components of a Pure 
Legacy Wrapper Component including a Legacy Wrapper 
Component, a Component Adapter, a Legacy Integration 40 
Architecture, a Legacy Adapter, and a Legacy System; 

FIG. 82 illustrates a Hybrid Component type of Legacy 
Wrapper Component; 

FIG. 83 shows an abstract example of the control flow in 
a Legacy Component; 

FIG, 84 illustrates a flowchart for a method for delivering 
service via a locally addressable interface in accordance 
with an embodiment of the present invention; 

FIG. 85 iUustrates Problems with Globally Addressable 
Interfaces in a system including cHents and servers with a 
plurality of interfaces; 

FIG. 86 illustrates the manuer in which the present 
invention uses a Locally Addressable Interface to hide 
functionality and lessen the load on the Naming or Trading 
Service; 

FIG. 87 illxistrates the manner in which the present 
invention obtains a Locally Addressable Interface; 

FIG. 88 illustrates the method in which the present 
invention registers and then locates a Globally Addressable qq 
Interface; 

FIG. 89 illustrates the manaer in which the present 
invention uses a GlobaUy Addressable Interface to obtain a 
Locally Addressable Interface to a specific Customer Object; 

FIG. 90 illustrates a flowchart for a method for commu- 65 
nicating a null value in accordance with an embodiment of 
the present invention; 
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FIG. 91 iflustrates the problem associated with sending a 
NULL across many types of middleware; 

FIG. 92 illustrates the manner in which the present 
invention passes a "null'' structure across the middleware; 

FIG. 93 depicts conversations with a "null" data structure; 

FIG. 94 depicts conversations with a non-"null" data 
structure; 

FIG. 95 illustrates a flowchart for a method for transmit- 
ting data from a server to a client via pages in accordance 
wiih an embodiment of the present invention; 

FIG. 96 depicts the response time for a User Interface to 
display a list of customers in a list box; 

FIG. 97 shows a request that returns a large amount of 
data; 

FIG. 98 shows a graphical depiction of a paging commu- 
nication pattem; 

FIG. 99 illustrates a message trace diagram showing the 
interactions between a Client and a Server using Paging 
Communication to satisfy the previously mentioned sce- 
nario; 

FIG. 100 iUiistrates a flowchart for a method for inter- 
facing a naming service and a cKent with the naming service 
allowing access to a plurality of different sets of services 
from a plurality of globally addressable interfaces in accor- 
dance with an embodiment of the present invention; 

FIG. 101 illustrates repeated requests to the Trader Ser- 
vice for the same interfaces; 

FIG. 102 fllustrates how a pool can be created that reuses 
GAI proxies; 

FIG. 103 illustrates the implementation of a Refreshable 
Proxy Pool; 

FIG. 104 iUustrales the class relationships between the 
patterns primary classes; 

FIG. 105 illustrates a flowchart for a method for providing 
a seff^describing stream-based communication system in 
accordance with an embodiment of the present invention; 

FIG. 106 iUustrates two systems communicating via . 
Stream-Based Communication and using a shared generic 
format to relay the meta-data information; 

FIG. 107 illustrates an object-based system with a fre- 
quently changing object model communicating via Stream- 
Based Communication; 

FIG. 108 illustrates a stream-based message that contains 
both message data and descriptive meta-data; 

FIG. 109 illustrates the manner in which a message 
language defines how to parameterize the meta-data and put 
it on the stream; 

FIG. 110 iUustrates a Customer object in an object-based 
system streaming itself into a stream, the stream being sent 
to a non-object system, this stream being read and the data 
inserted into a relational database; 

FIG. Ill iUustrates a flowchart for a method for providing 
a stream-based communication system in accordance with 
an embodiment of the present invention; 

FIG. 112 iUustrates how systems of the present invention 
communicate over a commimication mechanism that cannot 
inherently convey meta-data information; 

FIG. 113 is an Ulustration of an object-based system 
communicating with a non-object system iising a commu- 
nication mechanism that cannot convey meta-data informa- 
tion; 

FIG. 114 depicts an example of Stream Based Commu- 
nication with two disparate systems communicating via 
stream-based communication; 
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FIG. 115 is an illustration of a Customer object in an 
object-based system streaming itself into a stream, the 
stream being seat to a non-object system, this stream being 
read and the information is inserted into a relational data- 
base; 

FIG. 116 illustrates a flowchart for a method for efiBciently 
retrieving data in accordance with an embodiment of the 
present invention; 

FIG. 117 illustrates the manner in which a client requests 
information from server objects via a network; 

FIG. 118 illustrates the method of the present invention in 
which a client requests attributes from a server object via a 
network; 

FIG. 119 illustrates the transmitting of all data in a Data 
Structure firom a client to a server and visa-versa; 

FIG. 120 illustrates the method in which a client finds and 
instantiates a Customer Object from a customer component; 

FIG. 121 illustrates a Structure Based Communication 
that builds upon the method of FIG. 120 and depicts the flow 
of control during Structure Based Commimication; 

FIG. 122 shows Five Styles of Client/Server Computing; 

FIG. 123 illustrates a flowchart for a method for providing 
an activity module in accordance with an embodiment of the 
present invention; 

FIG. 124 iUuistrates multiple interfaces to an application 
including a handheld device, a desktop PC, and a telecom- 
munications device; 

FIG. 125 illustrates an activity entity relationship dia- 
gram; 

FIG. 126 illustrates a roles and responsibilities diagram; 

FIG. 127 iUustrates a typical implementation between a 
user interface and its activity; 

FIG. 128 iUustrates a flowchart for a method for struc- 
turing validation rules to be applied to a user interface for 
maximum maintainability and extensibility in accordance 
with an embodiment of the present invention; 

FIG. 129 illustrates widgets with their validation require- 
ments; 

FIG. 130 illustrates a user interface validator association 
diagram; 

FIG. 131 illustrates a validation rule class diagram; 

FIG. 132 illustrates a rule validation interaction diagram; 

FIG. 133 illustrates a flowchart for a method for assigning 
a view to an activity in accordance with an embodiment of 
the present invention; 

FIG. 134 illustrates a manner in which the maintain 
customer activity operation of the present invention 
launches its view; 

FIG. 135 illustrates the view configure launching the 
maintain customer view operation; 

FIG. 136 illustrates a flowchart for a method for testing 
successfulncss of an operation having pre-conditions and 
post-conditions that must be satisfied for the operation to be 
successful in accordance with an embodiment of the present 
invention; 

FIG. 137 illustrates an operation diagram depicting an 
example of pre-conditions and post-conditions; 

FIG. 138 illustrates a flowchart for a method for detecting 
an orphaned server context in accordance with an embodi- 
ment of the present invention; 

FIG. 139 illustrates a Client 1 that has instantiated A and 
C, deletes C but fails to delete A; 

FIG. 140 illustrates a GaibageCollector requesting for 
interest in context A; 
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FIG. 141 illustrates a Garbage Collector requesting for 
interest in context B; 

FIG. 142 illustrates a flowchart for a method for creating 
a common interface for exception handling in accordance 
5 with an embodiment of the present invention; 

FIG. 143 illustrates how having many different exception 
types will cause the exception handling logic to grow; 
FIG. 144 iUustrates that groupings are not always exclu- 
10 ^i^^^ 

FIG. 145 iUustrates a flowchart for a method for recording 
exception handUng requirements for maintaining a consis- 
tent error handling approach in accordance with an embodi- 
ment of the present invention; 
15 FIG. 146 illustrates a flowchart for a method for mini- 
mizing the amount of changes that need to be made to 
exception handling logic when new exceptions are added in 
accordance with an embodiment of tiic present invention; 
FIG. 147 depicts a program (i.e., the excq)tion handler of 
20 the present invention) with a few try-catch blocks; 

FIG. 148 depicts a program (the polymorphic exception 
handler) with smaller catch blocks; 

FIG. 149 Ulustrates a flowchart for a method for distrib- 
^ uting incoming requests amongst server components for 
optimizing usage of resources in accordance with an 
embodiment of the present invention; 

FIG. 150 iUustrates server components receiving service 
requests; 

30 FIG. 151 iUustrates a load balancer mediating the requests 
of FIG. 150; 

FIG. 152 iUustrates a flowchart for a method for main- 
taining a security profile throughout nested service invoca- 
tions on distributed components in accordance with an 
35 embodiment of the present invention; 

FIG. 153 iUustrates a component interaction diagram 
showing an interaction between a number of components in 
a financial system; 
FIG. 154 iUustrates a user manger/user context relation- 
^ ship diagram; 

FIG. 155 iUustrates a flowchart for a method for trans- 
lating an object attribute to and fi:om a database value in 
accordance with an embodiment of the present invention; 
45 FIG. 156 iUustrates that an attribute cannot be saved 
directly into the persistent store; 

FIG. 157 Ulustrates the use of an Attribute Converter to 
save an attribute into a database; 
FIG. 158 Ulustrates a flowchart for a method for control- 
50 Hng data in accordance with an embodiment of the present 
invention; 

FIG. 159 Ulustrates the data retrieval mechanism caUs 
being placed directly within the domain object; 

FIG. 160 shows the interrelationship between a database, 
a persist, and an account; 

FIG. 161 iUustrates that the database retrieval mechanism 
is separated from the business object by encapsulating the 
logic within a data handler; 

FIG. 162 Ulustrates the TiPersistcnceStream and TiMap- 
per of an embodiment of the present invention; 

FIG. 163 iUustrates a flowchart for a method for organiz- 
ing data access among a plurality of business entities in 
accordance with an embodiment of the present invention; 
65 FIG. 164 Ulustrates retrieving data piecemeal; 

FIG. 165 iUustrates the manner in which the present 
invention retrieves whole objects; 
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HG. 166 illustrates a flowchart for a method for retrieving 
multiple business objects across a network in one access 
operation in accordance with an embodiment of the present 
invention; 

FIG. 167 illustrates an example of an implementation of ^ 
the Multi-Fetch Object; 

FIG. 168 illustrates the Fetching of a Household object 
along with the other related objects using the multi object 
fetch results; 

FIG. 169 is an interaction diagram showing when the 
multi object fetch is not used; 

FIG. 170 illustrates a flowchart for a method for imple- 
menting an association of business objects without retriev- 
ing the business objects from a database on which the ^5 
business objects are stored in accordance with an embodi- 
ment of the present invention; 

FIG. 171 illustrates a flowchart for a method for mapping 
of retrieved data into objects in accordance with an embodi- 
ment of the present invention; 20 

FIG. 172 illustrates an Object Identity Cache in accor- 
dance with one embodiment of the present invention; 

FIG. 173 illustrates a flowchart for a method for separat- 
ing logic and data access concerns during development of a 
persistent object for insulating development of business ^ 
logic from development of data access routine in accordance 
with an embodiment of the present invention; 

FIG, 174 illustrates a flowchart for a method for providing 
a warning upon retrieval of objects that are incomplete in 
accordance with an embodiment of the present invention; 

FIG. 175 illustrates an Entity-Based Data Access System; 

FIG. 176 illustrates a Retrieving Data Piecemeal System; 

FIG. 177 illustrates a Commit and Rollback routine; 

FIG. 178 iUustrates Nested Logical Units of Work; 

FIG. 179 illustrates a flowchart for a method for allowing 
a batched request to indicate that it depends on the response 
to another request in accordance with an embodiment of the 
present invention; ^ 

FIG. 180 illustrates a Batching Retrievals and Depen- 
dency; 

FIG. 181 illustrates the Dynamically Setting Dependency; 

FIG. 182 illustrates a flowchart for a method for sending 
a single message to aU objects in a logical unit of work in 
accordance with an embodiment of the present invention; 

FIG. 183 iUustrates a Hand-crafted Message Forwarding 
scheme; 

FIG. 184 iUustrates a Generic Message Forwarding fea- 
ture; 

FIG. 185 iUustrates a flowchart for a method for batching 
logical requests for reducing network traffic in accordance 
with an embodiment of the present invention; 

FIG. 186 iUustrates the manner in which the present S5 
invention sends requests independenQy; 

FIG. 187 iUustrates a manner in which the present inven- 
tion registers requests; 

FIG. 188 fllustrates a flowchart for a method for sorting 
requests that are being unbalched from a batched message in ^ 
accordance with an embodiment of the present invention; 

FIG. 189 iUustrates an Ad Hoc Registration feature; 

FIG. 190 iUustrates a manner in which the present inven- 
tion sorts requests by weight; ^5 

FIG. 191 illustrates a flowchart for a method for assigning 
independent copies of business data to concurrent logical 
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units of work for helping prevent the logical units of work 
from interfering with each other in accordance with an 
embodiment of the present invention; 

FIG. 192 iUustrates the MVC Implementation with Global 
Model; 

FIG. 193 iUustrates the Separate Models for Separate 
Business LUWs; 

FIG. 194 iUustrates the Canceling of one LUW Indepen- 
dently of Another LUW; and 

FIG. 195 iUustrates the Context Copying Protects Context 
Boundaries. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A preferred embodiment of a system in accordance with 
the present invention is preferably practiced in the context of 
a personal computer such as an IBM compatible personal 
computer, Apple Macintosh computer or UNIX based work- 
station. A representative hardware environment is depicted 
in FIG. 1, which fllustrates a typical hardware configuration 
of a workstation in accordance with a preferred embodiment 
having a central processing unit 110, such as a 
microprocessor, and a number of other units interconnected 
via a system bus 112. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 114, Read Only 
Memory (ROM) 116, an I/O adapter 118 for connecting 
peripheral devices such as disk storage units 120 to the bus 
112, a user interface adapter 122 for connecting a keyboard 
124, a mouse 126, a speaker 128, a microphone 132, and/or 
other user interface devices such as a touch screen (not 
shown) to the bus 112, communication adapter 134 for 
connecting the workstation to a communication network 
(e.g., a data processing network) and a display adapter 136 
for connecting the bus 112 to a display device 138. The 
workstation typically has resident thereon an operating 
system such as the Microsoft Windows NT or Windows/95 
Operating System (OS), the IBM OS/2 operating system, the 
MAC OS, or UNIX operating system. Those skflled in the 
art wiU appreciate that the present invention may also be 
implemented on platforms and operating systems other than 
those mentioned. 

Apreferred embodiment is written using JAVA, C, and the 
C++ language and utilizes object oriented programming 
methodobgy. Object oriented programming (OOP) has 
become increasingly used to develop complex applications. 
As OOP moves toward the mainstream of software design 
and development, various software solutions require adap- 
tation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be appUed to a messaging 
interface of an electronic messaging system such that a set 
of OOP classes and objects for the messaging interface can 
be provided. 

OOP is a process of developing computer software using 
objects, including the steps of analyzing the problem, 
designing the system, and constructing the program. An 
object is a software package that contains both data and a 
coUection of related structures and procedures. Since it 
contains both data and a coUection of structures and 
procedures, it can be visualized as a self-sufficient compo- 
nent that does not require other additional structures, pro- 
cedures or data to perform its specific task. OOP, therefore, 
views a computer program as a coUection of largely autono- 
mous components, caUed objects, each of which is respon- 
sible for a specific task. This concept of packaging data, 
structures, and procedures together in one component or 
module is called encapsulation. 
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In general, OOP components are reusable software mod- 
ules which present an interface that conforms to an object 
model and which are accessed at run-time through a com- 
ponent integration architecture, A component integration 
architecture is a set of architecture mechanisms which allow 
software modules in different process spaces to utilize each 
others capabilities or functions. This is generally done by 
assuming a common component object model on which to 
build the architecture. It is worthwhile to differentiate 
between an object and a class of objects at this point. An 
object is a single instance of the class of objects, which is 
often just called a class. A class of objects can be viewed as 
a blueprint, from which many objects can be formed, 

OOP allows the programmer to create an object that is a 
part of another object. For example, the object representing 
a piston engine is said to have a composition-relationship 
with the object representing a piston. In reality, a piston 
engine comprises a piston, valves and many other compo- 
nents; the fact that a piston is an element of a piston engine 
can be logically and semantically represented in OOP by two 
objects. 

OOP also allows creation of an object that "depends 
from" another object. If there are two objects, one repre- 
senting a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the 
relationship between the two objects is not that of compo- 
sition. A ceramic piston engine does not make up a piston 
engine. Rather it is merely one kind of piston engine that has 
one more limitation than the piston engine; its piston is made 
of ceramic. In this case, the object representing the ceramic 
piston engine is called a derived object, and it inherits all of 
the aspects of the object representing the piston engine and 
adds further limitation or detail to it. The object representing 
the ceramic piston engine "depends from^' the object repre- 
senting the piston engine. Ihe relationship between these 
objects is called inheritance. 

When the object or class representing the ceramic piston 
engine inherits all of the aspects of the objects representing 
the piston engine, it inherits the thermal characteristics of a 
standard piston defined in the piston engine class. However, 
the ceramic piston engine object overrides these ceramic 
specific thermal characteristics, which are typically different 
from those associated with a metal piston. It skips over tbe 
original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different 
characteristics, but may have the same underlying functions 
associated with it (e.g., how many pistons in the engine, 
ignition sequences, lubrication, etc.). To access each of these 
functions in any piston engine object, a programmer would 
call the same functions with the same names, but each type 
of piston engine may have different/overriding implemen- 
tations of functions behind the same name. This ability to 
hide different implementations of a function behind the same 
name is called polymorphism and it greatly simplifies com- 
munication among objects. 

With the concepts of composition-relationship, 
encapsulation, inheritance and polymorphism, an object can 
represent just about anything in the real world. In fact, one's 
logical perception of the reality is the only limit on deter- 
mining the kinds of things that can become objects in 
object-oriented software. Some typical categories are as 
follows: 

Objects can represent physical objects, such as automo- 
biles in a traffic-flow simulation, electrical components 
in a circuit-design program, countries in an economics 
model, or aircraft in an air- traffic-control system. 
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Objects can represent elements of the computer-user 
environment such as windows, menus or graphics 
objects. 

An object can represent an inventory, such as a personnel 
^ file or a table of the latitudes and longitudes of cities. 
An object can represent user-defined data types such as 
time, angles, and complex numbers, or points on the 
plane. 

With this enormous capabihty of an object to represent 
just about any logically separable matters, OOP allows the 
software developer to design and implement a computer 
program that is a model of some aspects of reality, whether 
that reality is a physical entity, a process, a system, or a 
composition of matter. Since the object can represent 
anything, the software developer can create an object which 
can be used as a component in a larger software project in 
the future. 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 

^ able objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. 
Since 90% jdready came from an inventory of extensively 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 

^ OOP enables software developers to build objects out of 
other, previously buHt objects. 

This process closely resembles complex machinery being 
built out of assemblies and sub-assemblies. OOP 
technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fiilly support the 
OOP principles, such as encapsulation, inheritance, 
polymorphism, and composition -relationship. With the 
advent of the C++ language, many commercial software 
developers have embraced OOP. C++ is an OOP language 
that offers a fast, machine-executable code. Furthermore, 

^ C++ is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be 
the most popular choice among many OOP programmers, 
but there is a host of other OOP languages, such as 
Smalltalk, Common Lisp Object System (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more 
traditional popular computer programming languages such 
as Pascal. 

The benefits of object classes can be summarized, as 
follows: 

Objects and their corresponding classes break down com- 
plex programming problems into many smaller, sim- 
pler problems. 
Encapsulation enforces data abstraction through the orga- 

55 nization of data into small, independent objects that can 
commimicate with each other. Encapsulation protects 
the data in an object from accidental damage, but 
allows other objects to interact with that data by calling 
the object's member functions and structures. 

60 Subclassing and inheritance make it possible to extend 
and modify objects through deriving new kinds of 
objects from the standard classes available in the sys- 
tem. Thus, new capabilities are created without having 
to start from scratch. 

65 Polymorphism and multiple inheritance make it possible 
for different programmers to mix and match character- 
istics of many different classes and create specialized 
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objects that can still work with related objects in 
predictable ways. 
Qass hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real- wo rid objects 
and the relationships among them. 
Libraries of reusable classes are useful in many situations, 

but they also have some limitations. For example: 
Complexity. In a complex system, the class hierarchies for 
related classes can become extremely confusing, with 
many dozens or even hundreds of classes. 
Flow of control. A program written with the aid of class 
libraries is still responsible for the flow of control (i.e., 
it must control the interactions among all the objects 
created from a particular library). The programmer has 
to decide which functions to caU at what times for 
which kinds of objects. 
DupUcation of effort. Although class libraries allow pro- 
grammers to use and reuse many smaU pieces of code, 
each programmer puts those pieces together in a dif- 20 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes 25 
along the way. Inevitably, similar pieces of code end up 
doing similar things in sUghtly different ways and do 
not work as weU together as ttiey should. 
Gass hbraries are very flexible. As programs grow more 
complex, more programmers are forced to reinvent basic 
solutions to basic problems over and over again, A relatively 
new extension of the class library concept is to have a 
framework of class hbraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 
mechanisms that implement the common requirements and 
design in a specific application domain. They were first 
developed to free application programmers from the chores 
involved in displaying menus, windows, dialog boxes, and 
other standard user interface elements for personal comput- 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer called libraries provided by 
the operating system to perform certain tasks, but basically 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 

The development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These interfaces allow the user, rather than program logic, to 
drive the program and decide when certain actions should be 
performed, Tbday, most personal computer software accom- 
plishes this by means of an event loop which monitors the 
mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, 
a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
a program that is much easier to use. Nevertheless, indi- 
vidual pieces of the program written by the developer still 
call libraries provided by the operating system to accomplish 
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certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the 
event loop. Application code still "sits on top of the system. 

Even event loop programs require progranuners to write 
a lot of code that ^ould not need to be written separately for 
every application. The concept of an application framework 
carries the event loop concept frirther. Instead of dealing 
with aU the nuts and bolts of constructing basic menus, 
windows, and dialog boxes and then making these things all 
work together, programmers using application frameworks 
start with working application code and basic user interface 
elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework 
with the specific capabilities of the intended application. 

AppUcation frameworks reduce the total amount of code 
that a programmer has to write from scratch. However, 
because the framework is really a generic application that 
displays windows, supports copy and paste, and so on, the 
programmer can also relinquish control to a greater degree 
than event loop programs permit. The framework code takes 
care of almost all event handling and flow of control, and the 
programmer's code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data 
structure). 

A programmer writing a framework program not only 
relinquishes control to the user (as is also true for event loop 
programs), but also relinquishes the detailed flow of control 
within the program to the framework. Tliis approach aUows 
the creation of more complex systems that work together in 
interesting ways, as opposed to isolated programs, having 
custom code, being created over and over again for similar 
problems. 

Thus, as is explained above, a framework basically is a 
collection of cooperating classes that make up a reusable 
design solution for a given problem domain. It typically 
includes objects that provide default behavior (e.g., for 
menus and windows), and programmers use it by inheriting 
some of that default behavior and overriding other behavior 
so that the framework calls application code at the appro- 
priate times. 

There are three main differences between frameworks and 
class libraries: 

Behavior versus protocol. Qass libraries are essentially 
collections of behaviors that you can call when you 
want those individual behaviors in your program. A 
framework, on the other hand, provides not only behav- 
ior but also the protocol or set of rules that govern the 
ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide 
versus what the framework provides. 

CaU versus override. With a class library, the code the 
programmer instantiates objects and calls their member 
functions. It's possible to instantiate and call objects in 
the same way with a framework (i.e., to treat the 
framework as a class library), but to take full advantage 
of a framework's reusable design, a programmer typi- 
cally writes code that overrides and is called by the 
framework. The framework manages the flow of con- 
trol among its objects. Writing a program involves 
dividing responsibilities among the various pieces of 
software that are called by the framework rather than 
specifying how the different pieces should work 
together. 

Implementation versus design. With class libraries, pro- 
grammers reuse only implementations, whereas with 
frameworks, they reuse design. A framework embodies 
the way a family of related programs or pieces of 
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software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in 
a given domain. For example, a single framework can 
embody the way a user interface works, even though 
two different user interfaces created with the same 
framework might solve quite different interface prob- 
lems. 

Thus, through the development of frameworks for solu- 
tions to various problems and programming tasks, signifi- 
cant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the 
invention utilizes HyperText Markup Language (HTML) to 
implement documents on the Internet together with a 
general-purpose secure communication protocol for a trans- 
port medium between the client and the Ncwco. HTTP or 
other protocols could be readily substituted for HTML 
without undue experimentation. Information on these prod- 
ucts is available in T. Bemers-Lee, D. Connoly, "RFC 1866: 
Hypertext Markup Language — ^2,0" (November 1995); and 
R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C, 
Mogul, "Hypertext Transfer Protocol— HTTP/1.1: HTTP 
Working Group Internet Draft" (May 2, 1996). HTML is a 
simple data format used to create hypertext documents that 
are portable from one platform to another. HTML docu- 
ments are SGML documents with generic semantics that are 
appropriate for representing information from a wide range 
of domains. HTML has been in \ise by the World-Wide Web 
global information initiative since 1990. HTML is an appli- 
cation of ISO Standard 8879; 1986 Information Processing 
Text and Office Systems; Standard Generalized Markup 
Language (SGML). 

To date, Web development tools have been limited in their 
ability to create dynamic Web applications which span from 
client to server and interoperate with existing computing 
resources. Until recently, HTML has been the dominant 
technology used in development of Web-based solutions. 
However, HTML has proven to be inadequate in the fol- 
lowing areas: 

Poor performance; 

Restricted user interface capabilities; 
Can only produce static Web pages; 
Lack of interoperability with existing applications and 

data; and 
Inability to scale. 

Sun Microsystem's Java language solves many of the 
client-side problems by: 
Improving performance on the client side; 
Enabling the creation of dynamic, real-time Web appli- 
cations; and 

Providing the ability to create a wide variety of user 
interface components. 

With Java, developers can create robust User Interface 
(Uf) components. Custom "widgets" (e.g., real-time stock 
tickers, animated icons, etc.) can be created, and client-side 
performance is improved. Unlike HTML, Java supports the 
notion of client-side validation, oflaoading appropriate pro- 
cessing onto the client for improved performance. Dynamic, 
real-time Web pages can be created. Using the above- 
mentioned cxistom UI components, dynamic Web pages can 
also be created. 

Sun's Java language has emerged as an industry- 
recognized language for "progranuning the Internet." Sun 
defines Java as: "a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture -neutral, portable, 
high-performance, multithreaded, dynamic, buzzword- 
compliant, general-purpose programming language. Java 
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supports programming for the Internet in the form of 
platform-independent Java applets." Java applets are small, 
specialized applications that comply with Sun's Java Appli- 
cation Programming Interface (APT) allowing developers to 
5 add "interactive content" to Web documents (e.g., simple 
animations, page adorimients, basic games, etc.). Applets 
execute within a Java-compatible browser (e.g., Netscape 
Navigator) by copying code from the server to client. From 
a language standpoint, Java's core feature set is based on 
C++. Sun's Java literature states that Java is basically, "C++ 
with extensions from Objective C for more dynamic method 
resolution." 

Another technology that provides similar function to 
JAVA is provided by Microsoft and ActiveX Technologies, 
to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D vir- 
tual reality, video and other multimedia.cc)|itent..The tools 
use Internet standards, work onSSSt^e^tatforais, and are 
being supported by over 100 companies. The group's build- 

20 ing blocks are called ActiveX Controls, small, fast compo- 
nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 
ing Microsoft \^ual C++, Borland Delphi, Microsoft \^sual 

25 Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of 
ordinary skill in the art readily recognizes that ActiveX 

30 could be substituted for JAVA without undue experimenta- 
tion to practice the invention. 
Overview 

Architecture Basics 
Architecture Overview 

35 What is architecture? 

Architecture — whether the word is applied to work with 
a city skyline or an information system — ^is both about 
designing something and about making, building, or con- 
structing something. An architect is literally a "master 

40 builder" — ^from the Greek words archi (primary or master) 
and tekton (builder or carpenter). In good Greek fashion, 
however, it would be unthinkable for something to be btiilt 
without a sound theoretical basis. So architecture involves 
theory, but there is nothing merely theoretical about it. 

45 Conversely, architecture is also eminently practical, but 
there is nothing merely practical about it. Ideas about form 
and structure lie behind architecture. Ultimately one must let 
go of a mindset that tries to separate the designing from the 
making; they exist together as a whole, and to extract one 

50 without the other is to kill the whole. 

Architecture also is an engineering discipline. It creates 
and also depends on a structured maimer to analyze and 
design whatever is to be built. Like all living disciplines, 
architecture continues to grow and evolve. Engineering 

55 discoveries move the field forward. Certain design and 
engineering principles clearly show themselves to be suc- 
cessful in practice, and these then become repeatable com- 
ponents of additional work. The ability to continue to master 
each component, as well as the interrelations among 

60 components, is a distinguishing characteristic of architec- 
ture. 

So architecture is about designing and building something 
from a set of basic components, and also about the interre- 
lations among the components. And it is a discipline 
65 whereby all these things come together — materials, space, 
people — to bring something into being that was not there 
before. 
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Although building architects have not always been 
pleased about it, architectuial concepts have influenced 
other kinds of "building" projects for some time. Over the 
past twenty years, developers of information systems, for 
example, have used concepts from the field of architecture 5 
not only to describe their work but to execute it, as well. 

The use of architectural thinking implies that the work is 
about creating certain kinds of structures that can be engi- 
neered or at least influenced, and that the work can be 
organized and performed in a structured, systematic manner 
Moreover, use of architectural concepts implies that there is 
something repeatable about the work: architects can create a 
structure, then use components of that structure again in the 
future when they come across a similar situation. 

An architectural paradigm should not be lightly used. It 
makes demands. To use architectural concepts implies that 
clients arc ready to do so — that is, that the field is sufiBciently 
mature in its work to see patterns and to organize future 
work according to those patterns. 

Finally, architecture must be understood as a process 200, 
not just a thing. This process can be described at a very high 
level using FIG, 2. 
Step 1: Analyze 202. The architect must begin by listening 
to and researching the needs of the client. What is the 
function of the building? What is its environment? ^ 
What are the limitations set by budget and use? 
Step 2: Design 204. This is a blueprint stage. The architect 
creates one or several designs showing the layout of the 
structure, how different spaces fit together, how every- 
thing looks from different views, what materials are to 
be used, and so forth. 
Step 3: Model & Test 206. Not every architectural project 
has this step, but in many cases, the architect will create 
a scale model/prototype of the finished product, allow- 
ing the client a clearer sense of what the ultimate 35 
solution will look like. A model is a kind of test stage, 
allowing everyone to test the design in a near-real-life 
setting. 

Step 4: Build 208. This is the actual construction of the 
building, in general accord with the blueprints and 40 
prototype. 

Step 5: Operate and Evolve 210. The building is to be 
lived in and used, of course, and so an important step 
is to ensure that the finished product is tended and 
operated effectively. Architects themselves may not be 45 
involved in the operation of their building, but they 
certainly would be involved in future expansions or 
evolutions of the building. Stewart Brand's recent text, 
How Buildings Learn, argues that effective architecture 
takes into account the foct that buildings "learn": as 50 
people live and work in them over time, those people 
will seek to alter the building in subtle, or not so subtle, 
ways. 

Also, when architects design a building, they have in their 
heads a primary conceptual framework for aJl the compo- ss 
nents that go into that building: the plumbing, the electric, 
the sewers, stairs/elevators, framing stracture, and so forth. 
The tacit step for an architect is, "Based on my knowledge 
of the generic components that go into a building, how wiU 
these components fit together in this particular building? eo 
Which of these components will require special attention 
because of the functional demands of the building?" 
Oxford Enghsh Dictionary Definition 

The conceptual structure and overall logical organization 
of a computer or computer-based system from the point 65 
of view of its use or design; a particular realization of 
this. 
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Gartner Group Definition 

The manner or structure in which hardware or software is 
constructed. Defines how a system or program is 
structured, how various components and parts interact, 
as weU as what protocols and interfaces are used for 
communication and cooperation between modules and 
components which make up the system. 

Gartner Group sets forth seven general characteristics of 
successful architectures. 

Delimitation of the problem to be addressed 

Decomposition of the solution to components with clearly 
assigned responsibilities 

Definition of interfaces, formats, and protocols to be used 
between the components. These should be sufficiently 
clear and robust in order to permit asynchronous devel- 
opment and ongoing reimplementation of the compo- 
nents. 

Adequate documentation to permit compliance by imple- 
menlors 

An auditing mechanism that exercises the specified inter- 
faces to verify that specified inputs to components yield 
specified results 

An extendibility mechanism to enable response to chang- 
ing requirements and technologies 

Policies, practices, and organizational structures that 
facilitate adoption of the architecture 

What types of architectures are discussed in the following 
description? 

Standard Architecture Framework (SAF) 300 provides 
access to the iiser's thought leadership and architecture 
frameworks for Execution, Development and Operations 
environments 302, 304, 306. For a more detailed discussion 
on these architectures, please see Standard Architecture 
Summaries (below). FIG. 3 shows the dependencies of the 
three architecture frameworks and is described in more 
detail in the Delivery Vehicle Overview (below). 

The following lists are starting points for considering the 
range of components and activities that must be covered by 
each architectural view of the system. They are not a 
definitions of the environments. 
Standard Architecture Summaries 
Execution Architecture 302 

Tlie execution architecture is a unified collection of 
run-time technology services, control structures, and sup- 
porting infrastructure upon which application software runs. 

It includes components such as: 

Application messaging 

Batch processing architecture 

Middleware 

Reporting 

Error handling 

On-line architecture 

Security 

Code/decode 

Data access methods 

Integrated help 

File transfer capabilities 

Directory services 

Load balancing 

Workflow services 

State management 

"Special" requirements (e.g., workflow, telephony, 
groupware) 
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Development Architecture Framework 304 

Hie Development Architecture Framework (DAF) is a 
unified collection of technology services, tools, techniques, 
and standards for constructing and maintaining application 
software. 5 

It includes components such as: 

Design/documentation tools 

Information repository 

Project Management tools 

Program Shells 

GUI Window painter 

Prototyping tools 

Programmer APIs 

Testing tools 

Source code control/build process 

Performance test tools 

Productivity tools 

Design tools 

Compiler/debugger 

Editor 

Refer to the Development Architecture Framework appli- 
cation (referenced above) for more Information 25 
Operations Architecture 306 

A unified collection of technology services, tools, stan- 
dards and controls required to keep a business application 
production or development environment operating at the 
designed service level. It differs from an execution archi- 30 
tecture in that its primary users are system administrators 
and production support personnel. 

It includes components such as: 

Job scheduler 

Software distribution 35 

Error monitor 

Data backup and restore 

Help desk 

Security administration 40 

High-Availabihty 

Hardware management 

Performance monitors 

Startup/shutdown procedures 

Report management tool 

Disaster Recovery 

Network Monitoring Tools 

Cross Platform Management Tools 
Considerations — All Environments 

To ensure that you are asking the right questions about the 
technology architecture, you must refer to the Architecture 
Checklist (available from the Content Finder). Questions 
will include: 

For all technology components, have the following char- 
acteristics been addressed: 
Performance according to specifications? 
Reliability of operation? 

Ease of operation? 60 
Maintenance requirements? 

Ability to interface with other components, particularly 

those from other vendors? 
Delivery schedule to provide adequate pre -conversion 55 

testing? 
Backup procedures? 



45 



50 



55 



Vendor reliability and financial stability? 

Future proofing against biisiness change? 

Have the versions of system software been Uve at another 
site for at least six to twelve months? 

This time frame varies by product. Have reference sites 
been verified? 

What is a framework? 

It is a major challenge to design the complex infrastruc- 
ture that is needed to satisfy the requirements of today's 
distributed, mission-critical applications. As such, it is help- 
ful to have an inventory of the components that may be 
required for the design, build, installation and operation of 
systems. It is also helpful to have an understanding of how 
the components fit together conceptually. 

A Framework should be thought of as a conceptual 
structure used to frame the work about to be done. It should 
be used as a thought trigger or as a completeness check. You 
cannot build from a framework directly but instead should 
use it as a starting point for understanding and designing. 

Frameworks are used to help practitioners understand 
what components may be required and how the components 
fit together. Based on the inventory of components and the 
description of their relationships, practitioners will select the 
necessary components for their design. An architect extracts 
components from one or more Frameworks to meet a 
specific set of user or application requirements. Once an 
architecture has been implemented it is often referred to as 
an architecture or an infrastructure. 

The scope of what a framework addresses can vary 
widely. One framework, for instance, may outline the com- 
ponents for a technical infrastructure in its entirety whereas 
another framework may focus explicitly on the network. A 
thorough understanding of a framework's scope is crucial to 
its use during the design phase of a project. 

It is also important to understand whether the framework 
is vendor specific in nature (proprietary) or whether it is 
available for use by a large number of vendors (open). 

Why is architecture important? 

One has seen the benefits of an architectural approach to 
information systems development: better productivity and 
less reinvention of the wheel. An architecture provides a 
completeness check, ensuring that all relevant components 
of a possible solution have been considered. It ensures 
consistent, reliable, high-quality applications. It gives 
everyone — the developers and their clients — a common 
framework and common language with which to talk about 
the work. 

Perhaps most important, it allows developers to leverage 
successful solutions when performing additional work. 
Architecture involves repeatable concepts, and so it reduces 
the time and cost by which a solution is delivered. 

Some of the specific technical benefits of a good archi- 
tecture are: 

Simplified Application Development 

Provides common set of application services. Removes 
application programmers firom the complexities of the 
underlying technology and development tools, allow- 
ing less experienced developers to be more productive. 

Quality 

Usually more experienced developers implement the 
often complex technical components in an architecture. 
These components are then reused, avoiding duplicated 
complex logic in the applications. Iterations during 
design, implementation and testing often result in 
refinement and improvement of the architecture com- 
ponents. All users of these components benefit from 
such improvements, reducing the risk of failure and 
ensuring better overall quality in the final application. 
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iDtegration 

An architecture often ties together disparate software, 
platforms and protocols into one comprehensive frame- 
work. 

Extensibility 5 
The architecture is established by experienced personnel 
who can predict with some confidence whether a given 
architecture will fulfill cunent and future requirements. 
Code extensions are easily integrated. A well-balanced 
architecture consists of the "right" components, where 
the components are tied together by simple 
interrelationships, since complex relationships increase 
the architecture's complexity faster than modulariza- 
tion can reduce it. 

Location Transparency 
Divorces application from the details of resource location. 
This is however not always true or required. For 
performance reasons designers and developers still 
often need to be aware of process and data locations. ^ 

Horizontal Scaling 
Assist in optimal utilization of existing infrastructure 
resulting in increased application performance and sta- 
bility. 

Isolation 25 
An architecture can be used to isolate the applications 
from particular products. This ensures that products can 
more easily be replaced later. This characteristic can be 
important if there is risk associated with a product^s or 
product vendor's future, or the rate of change in a 30 
particular technology area is particularly high. An evi- 
dent example is looking back at changes in past user 
interface standards. Applications that did not separate 
user interface logic from business logic, had to be 
completely rewritten to take advantage of new user 35 
interfaces, such as MS Wndows and more recently 
Web browsers. 

Portability 

Increases portability and reusability within and across 
different platforms or protocols. 40 

The use of architecture frameworks during analysis and 
design can reduce the risks of an IT solution. It should 
improve development productivity through reuse, as well as 
the IT solution's reliability and maintainability. 

One key challenge for today's IT managers is the need for 45 
change. Architectures provide a basic framework for major 
change initiatives. Clients' core business is performed by 
strategic applications that wiU most likely require frequent 
and rapid development to handle changes in technology 
capability and business requirements. A properly defined 50 
and intelligently developed architecture delivers an infra- 
structure on which clients can build and enhance applica- 
tions that support their cunent and future business needs. 
This is how one helps clients to manage change. 

A key benefit of an architecture is that it divides and 55 
conquers complexity. Simple applications benefit less from 
architecture than complex ones do; fewer decisions are 
needed in these cases, and fewer people need to know about 
them. During maintenance, a poorly architected small appli- 
cation is tolerable because it is still relatively easy to locate 60 
a fault and to anticipate the side effects of correcting it. 
Conversely, complex applications are more difficult to 
understand and to modify. Complexity is reduced by sub- 
dividing the ^pUcation in layers and components, each 
layer having a specific functionality. The layers are strongly 65 
cohesive and de-coupled: A given layer docs not need to 
know the internals of any other layer. 
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The following quote from a recent study of Large Com- 
plex Systems (LCS) stress the importance of a stable archi- 
tectures in large systems: 

Successful delivery of an LCS solution depends on the 
early definition and use of common data applications 
and technology architecture. 

There is a high failure rate when the architecture is not 
defined, stabilized, and delivered early in an LCS effort. 

All significant LCS efforts involved the use of common or 
shared architectures. A successful effort, however, 
depended on early definition and delivery of a stable 
common architecture. 

Significant changes to the data, application, or technology 
architectures had severe negative effects on the time- 
liness of project deliverables, and on the reliability of 
what was delivered. 

PROJECT! and PROJECTZ, for example, experienced 
unusual circumstances. While the client evaluated 
whether to proceed, one defines and designs the archi- 
tecture. As a result, the teams had nine months to 
define, design, and begin implementation of required 
data, applications, and development architectures. 
Although in each case these architectures continued to 
evolve with business and technology needs, they 
remained largely consistent with the initial design. This 
consistency proved to be essential to the timely deliv- 
ery of the applications. 

At PROJECTS and PROJECT4, on the other hand, the 
architectures went through major evolutions as the 
developers created the applications. The overall result 
was that those efforts experienced delays relative to 
plan. 

Although it is not realistic for every project to have nine 
months to define required architectures, it does suggest 
that early focus on definition and design of the archi- 
tectural components is essential 
The risk of failure is greatly increased if essential archi- 
tectures are being defined or changed significantly in 
parallel with application development. 
What are the benefits of an architecture? 
The benefits derived from a technology architecture may 
allow a user to be in the forefront of the development of 
many leading edge business solutions. The investment in a 
reliable and flexible architecture can result in one or more of 
the following: 

Preservation of investments in applications and technol- 
ogy by isolating each from changes in the other (e.g. 
upgrades in hardware or third-party software do not 
impact applications). 

Leveraging scarce technical skills (e.g. the need for 
people with detailed skills in a specific communications 
protocol or aspects of SQL). 

Enhancements in productivity, flexibility and maintain- 
ability because common and often complex and error- 
prone components (e.g. error handling or cross- 
platform communications) arc created within the 
architecture, and then reused by all applications. 

Increases ia the predictability of application performance 
because the run-time behavior of common components 
is familiar and consistent. 

Serves as a construction blueprint and discussion agenda 
and ensures consistency across systems. This can have 
a big impact on the oper ability and maintenance of the 
delivered applications. 
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What is an architect? Delivery Vehicle Matdx 

Architects must have deep understanding of a project, FIG. 4 illustrates a dehvery vehicle matrix 400. One way 

business and/or technical environment. Architects are of looking at a Delivery Vehicle is therefore as an intersec- 

involved aaoss business integration projects, managing ^on of a technology generation 402 and application style 

their complexities and intricacies. 5 404. This is the presentation method currendy adopted for 

How advanced should an architect be? navigation in SAF. 

It is easy to go overboard when designing and implement- Delivery Vehicle Cube 

ing a technology architecture. Ideally the architecture should ^h^ DeUvery Vehicle Cube 500, iUustrated in FIG. 5, 

be a thin, well-defined layer that ensures development represents the "fiill" picture of what a Delivery Vehicle is. In 

productivity, maintenance flexibility, performance and sta- lo addition to the Application Styles and the Technology gen- 

[)j[[ly erations it introduces a distinction between Execution, 

A key issue is maintainability and operabiHty. Keep in Development and Operations Environments 502,504,506. 

mind that others may have to understand the rationale following dimensions, or cube "faces: 

behind the architecture design in order to correctly maintain 1. On the bottom left face of the cube are the core 

[I j5 technology components and services 508 that are com- 

Architecture logic can quickly become very abstract and across all delivery vehicles, 

hard to maintain by others than those who built it. A These core services may be implemented using one or 

carefuUy designed architecture can quickly be destroyed by several of the Technology Generations; currently Host, 

maintenance personnel that do not understand how it was Client/Server or Netcentric, Most major enterprises have 

designed and developed. 20 legacy systems that include both host based and distributed 

You should make your architecture as light-weight as client/server applications. Netcentric applications may 

possible only addressing the requirements that drive it. extend the mix of system technologies. 

Avoid "nice to have" flexibility and additional levels of 2. On the top left of the cube are the technology compo- 

abstractions that are intellectually interesting but not strictly nents 510 that are required to support a distinct delivery 

required. 25 vehicle. 

Delivery Vehicle Overview These components extend the technology architecture 

A DeUvery Vehicle is an integrated collection of technol- ^ith services that are specific for each distinct deUvery 

ogy services that supports an appUcation style, implemented vehicle. Some of the components may extend some of the 

on a distinct architecture generation. services. 

Application Style ^ ^* ^p^^ °^ three environments 

An application style defines a unique class of processing ''^^'"K'^jflt ''^'*l°P- 

type, which is used by applications, and thus end-useis. „ operations 502^04,506. 

DeUvery Vehicle Reference set of Application Styles inchide services and the dehvery vehicle extensions 

batch, on-line transaction processing, coUaboration, data squire support in all three environments. The cube illus- 

warehouse. knowledge management and integraUon. "^'^^ '^ff"*"' ^^''J'^^^ """y '^t'^"' 

r« A V *• o* 1 • *u • J- c extensions to a core development or operations 

The Apphcation Style is the pnmary dimension of a , . - * *t- t.-* _^ a • • 

!• Tfl* 1 A J. environment, not lust the execution arcoitecture. A mission- 

Dehvery Vehicle, and most people use the terms Application . " rr . J J"^" ^j^^ua^^h ^v^ii^..tui^. ^ iLua^iwu 

oi 1 J 1- ^7 1 * *L critical high-volume transaction delivery vehicle may 

Style and Dehvery Vehicle to mean the same thmg. . - ^ ^ ^ • . i • /t. j i ^ 

■^^ , , . . ^ . , reqmre ajecial performance tunmg tools in the development 

Akey goal with a dehvery vehic e IS that it can be reused ^ architecture, as well as real-time monitoring tools in the 

across many apphcaUons. It is still part of the Technology operations architecture. 

Architecture not involving application specific logic. An Also different technology generations may require special 

AppUcaUon Architecture on the other hand, will be specific ^^^^^ ^ ^^^^ enviromnents. When working in a 

for a particular application. multi-platform environment, there may be duplicated ser- 

Architecture GeneraUon 45 vices across platforms. This usually complicates 

An architecture generation is a broad classification development, operations and execution architectures and 

scheme for placing technology components within a tech- may require special focus on providing an integration archi- 

nology era. Delivery Vehicles are physically implemented lecture. 

on a distinct architecture generation. Examples of architec- The following figure illustrates the relationship between 

ture generations include host-based, client-server and net- 50 the three environments and the overall business system: 

centric. Topically, one may focus on engagements regarding the 

Note: Defining a clear line between what falls under the execution environment. The main dependency between 

client/server and a Netcentric technology generation is dif- these three environments is that the execution architecture to 

ficult; typically different people tend to have different opin- a large degree drives the requirements for the development 

ions. Technologically, the Netcentric generation may be an 55 and operations architectures. For example if a 

evolution of the client/server generation. In the context of heterogeneous, distributed execution architecture is 

the Delivery Vehicles, the technology generation discussion selected, both the development and operations environments 

may be intended to be a logical discussion that aims to must reflect this. 

highlight the new business capabilities enabled by new How can the delivery vehicle framework be useful? 

technologies. So for example, there could be a PowerBuilder 60 Refocus users and clients toward business solutions and 

application executing from a Web Browser using a plug-in. away from technology issues. 

Whether this is called a client/server or Netcentric applica- Help you link architecture plaiming deliverables to deliv- 

tion is up to the reader. When presenting technology archi- ering. 

tecture information to clients, focus on the business capa- Create an enterprise-wide view of the business capabih- 

bilities that arc offered by technologies rather than just on 65 ties enabled by technologies. 

definitions for what is client/server or what is Netcentric Provide new architecture frameworks needed today to 

technology. meet you're a user's client's business needs. 
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Provide guidance to define what architecture best meets 
you're a user's client's business needs. 

Provide standard ardiitecture frameworks and best prac- 
tices to build these architectures. 

During a high-level architecture design, help the user 5 
identify architecture services the user will need to address, 
by providing a logical level discussion one can use to assess 
types of base services and products needed for the specific 
situation. 

When Delivery Vehicles are implemented, they reduce 
time to implement business solutions by providing "Starter 
Kits" architectures. 

When Delivery Vehicles are implemented, they leverages 
technology across the business by: 

reducing operations and maintenance costs by limiting the 15 
number of different technologies and skills required to 
support these technologies. 

reducing technology costs for execution & development. 

Note: The Delivery Vehicle Framework presents a way to 
organize technology architecture information. When pre- 20 
senting this type of content client, one may need to tailor the 
information they present based on the client's background 
and the terminology they are familiar with. 
Technology Generation Selection 

Introduction 25 

This section should assist an architect in understanding 
the characteristics of, and the implications from selecting, a 
specific technology generation. The strengths and weaJc- 
nesses of each technology generation should be understood 
when planning and designing a system. When identifying 30 
the core technologies to be used in an architecture, a view of 
the chent's existing IT architecture 600, guiding principles 
602 and business imperatives 604 should be taken into 
consideration, as depicted in FIG. 6. 

It is important to realize that a distinct, static division does 35 
not exist between the different technology generations. It is 
possible that an architecture may consist of components 
from more than one generation. 

The goal should be to understand the pros and cons of the 
different technology options available for each component 40 
and to select the most appropriate one based on the client's 
requirements. 

It is becoming more important to leverage existing sys- 
tems and integrate them with new applications. A typical 
scenario can involve mainframe legacy systems acting as 45 
servers in a client server architecture, application servers 
being accessed from both traditional GUI clients built in 
Powerbuilder and Visual Basic and from Web-based fironl 
ends accessing the application servers via a Web-server. 
General Considerations 50 

From a technology point of view a new custom-made 
application should generally use the most recent Architec- 
ture Generation to assure that the application will live longer 
by better being able to adapt to future changes. 

This implies that most applications should ideally be 55 
based on a Netcentric Architecture, rather than on a tradi- 
tional client/server or a host-based architecture . 

However choosing a generation is not just a technical 
decision. Often key technology architecture decisions are 
made as a result of factors which are completely non- 60 
technical in nature, such as financial factors, internal and 
client politics (say no more), and implementation/ 
operational considerations. 

When deciding whether to employ a Netcentric solution, 
i.e. incorporating Web-based user interfaces and Internet 65 
application styles, keep in mind that these technologies are 
not a panacea and should be used only when there is solid 
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business reason. They require new investments in skills, 
tools, development and operations processes. Due to the 
relative immaturity of tools and products, they also represent 
additional risks both in technical terms, such as performance 
and reliability, and in strategic terms, such as vendor and 
product quality and stability. 

Regardless today each project should always consider the 
prospect of utilizing Netcentric technologies. It is important 
to evaluate whether the application can benefit firom a 
Netcentric style implementation immediately or in the 
future. 

Even if a traditional client/server approach (e.g. using 
Visual Basic or PowerBuilder) is decided upon, the use of 
Netcentric concepts to produce significant reductions in 
software packaging and distribution costs should be consid- 
ered. Such concepts include three- or multi-tier architectures 
with more business logic residing on server, flexible security 
architecture, and user interface concepts that can be ported 
to a Web Browser at a later stage. 

A Netcentric architecture will usually still support devel- 
opment of client/server applications. The opposite is not 
often true since traditional client/server systems usually 
keep a substantial portion of the business logic on a fat 
client, while Netcentric architectures still favor keeping 
most business logic at the server side. Also Netcentric 
architectures tend to be more loosely coupled than (the still 
dominant two-tier) client/server systems. 

The following sections identify the main characteristics 
associated with a Netcentric, Client Server or Host based 
technology generation. This list should in no way be con- 
sidered complete and exhaustive but is incltided as a starting 
point from which the identification process may begin. 
Network Centric Architecture Generation 

If, based upon one's chent's requirements, most of the 
statements in FIG. 7 are true, one should consider an 
application based upon the Netcentric technology genera- 
tion. 

The following details the importance of each of the 
statements in FIG. 7 and should assist one in identifying the 
appropriate answer for the specific client engagement. 
Existing Architecture and Infrastructure 700 

El, Other Netcentric applications been developed and 
placed in production. 

The user community is often less resistant to accept the 
use of new technology to address changing business 
drivers if they are not completely unfamiliar with the 
characteristics of the technology. If an application 
based on a Netcentric architecture has akeady been 
successfully piloted or deployed, acceptance of addi- 
. tional systems will be eased, 

E2. The client has significant technology skills within its 
FT department. 

This is especially important if the client plans on devel- 
oping or operating the application themselves. A sig- 
nificant investment in training and changes to internal 
organizations may be necessary for successful deploy- 
ment of this type of system. The client must have a 
culture that supports change. Some organizations are 
very conservative and strong, making it difficult to 
deliver a successful project using new technology. 

E3. The client has multiple hardware/operating system 
configurations for their client machines. 

In traditional client/server environments, distributing an 
application internally or externally for an enterprise 
requires that the application be ported, recompiled and 
tested for all specific workstation operating systems. 
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Use of a Universal Client or web-browser may elimi- 
nate many of these problems by providing a consistent 
and familiar user interface on many different operating 
systems and hardware platforms. 

E4. The application will run on a device other than a PC. 

The momentum of the Internet is putting a lot of pressure 
on vendors of various devices to be web-enabled. 
Having the Intemet infrastructure in place makes it 
more feasible for vendors to create new physical 
devices from which electronic information can be 
accessed. For example, Web televisions are gaining 
momentum. Now users can access the Intemet from a 
television set. Network Computers, thin-client devices 
that download and run applications from a centrally 
maintained server are generating a lot of interest. Also, 
users want to have access to the same information from 
multiple physical devices. For example, a user might 
want to have access to his/her e-mail from a cellular 
phone, from a Web TV or their portable PC. 

E5. The current legacy systems can scale to serve a 20 
potentially large new audience. 

Expanding the user community of a legacy host or client/ 
server system by including an audience which is exter- 
nal to the company can result in dramatic increases in 
system usage. The additional demand and increased ^ 
usage placed on existing legacy systems is often diffi- 
cult to estimate or predict Analysis must be conducted 
to ensure existing legacy systems and infrastmcture can 
absorb this increase. 
Business Imperatives 702 

Bl. The client needs to reach a new external audience 
with this application. 

This is probably the main reason for selecting a Netccntric 
architecture. Through appropriate use of a Netccntric 
architecture it is often possible to gain exposure to new 
customers and markets. The client can often achieve 
significant competitive advantage by providing new 
services and products to its customers. Also this new 
channel makes it technically possible to develop a new 
generation of "market-of-one" products, where each 
customer can repeatedly and easy customize a product 
according to own preferences. 

B2. The client needs to reach a large or diverse internal 
audience with this apphcation. 

Configuration management of traditional client/server 
applications, which tend to be physically distributed 
across both the client and server, is a major issue for 
many corporations. The software distribution of such 
applications which are packaged as one large or a 
combination of a few large executables makes minor 
updates difficiilt for even a small scale user population. 
Every time an update is made, a process must be 
initiated to distribute new code to all cUent machines. 
The browser-centric application style offers an alterna- 
tive to this traditional problem of distributing function- 
ality to both internal and external users. 
IT Guiding Principles 704 

Gl. The chent is an early adopter of new technology. 

Implementation of a Netcentric architecture can help the 
cUent realize a number of business benefits. However, 
the introduction of new technology into an organization 
does have inherent risks and can result in a significant 
amount of change. The client should have a culture 
which can embrace these necessary changes. 

G2. Applications should be developed to handle non- 
dedicated or occasional users. 
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Non-expert users need a simple to use and familiar 
interface in order to be able to use the application. As 
people grow accustomed to Web-browsers, this will be 
their preferred user-ioterface. The consistent interface 
provided by the Web-browsers wiU help reduce the 
learning curve necessary for becoming familiar with 
new apphcations. 
03. Where appropriate, applications should be developed 
with multi-media capabilities for the presentation of 
data (text, sound, video, etc.). 
The abihty to digitize, organize, and deUver textual, 
graphical and other information (e.g., video, audio, etc.) in 
addition to traditional data to a broader audience, enables 
new methods for people and enterprises to work together. 
Netcentric technologies (e.g., HTML documents, plug-ins, 
Java, etc.) and standardization of media information formats 
enable support for these types of complex documents and 
applications. Network bandwidth remains a performance 
issue. However advances in network technologies and com- 
pression techniques continue to make richer media-enabled 
documents and applications more feasible on the Web. 
G4. The Execution, Operation and Development archi- 
tectures wiU be designed to support frequent releases of 
enhancements/modifications to production applica- 
tions. 

It is imperative that companies in the current market place 
be able to quickly modify their business processes in 
order to address changes in the industry. 

A Netcentric architecture simplifies frequent software 
releases for both intemal and external users of the 
systems. 

Client/Server Network Generation 

If, based upon a client^s requirements, most of the state- 
ments of FIG. 8 are true, one should consider an application 
based upon the Client Server technology generation. 

The following section details the importance of each of 
the statements found in FIG. 8 and should assist one in 
identifying the appropriate answer for your specific chent 
engagement. 

Existing Architecture and Infrastructure 800 
El. Other Client Server applications been developed and 
placed in production and the client IT organization 
contains persoimel famihar with client server architec- 
ture concepts. 

As with any new technology, there is a learning curve 
related to attaining chent server development skills. 
The development process is often much more efficient 
when familiar tools and environments are used. The 
introduction of new technology can also create insta- 
biUty in the operations environment. Client/server sys- 
tems still represent a new technology to many IT 
departments. 
Business Imperatives 802 
Bl. The application will be used only by an internal user 
community. 

Software distribution is a concern for traditional chent 
server computing enviroimients due to the fact that 
executable and data files need to reside on the chent 
hard drive. Distribution to a user community outside of 
the client's organization is even more difficult to imple- 
ment and manage and will probably be limited to a few 
key business partners. 

B2, The application requires an advanced, dynamic, and 
integrated user interface for expert users. 

State of the art 4GL and 3GL development languages will 
support advanced user interfaces which require a sig- 
nificant degree of context management between fields 
and windows. Web -based user interfaces do not support 
such interfaces well yet. 
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B3. Session perfonnance is critical to the application or 
sub-second response times are required for successful 
use. 

aient server applications can provide response times 
necessary to support transaction intensive mission criti- ^ 
cal systems. Application logic and business data can be 
distributed between the client and server for optimal 
efficiency. Web-based interfaces still have an inherent 
overhead due to the connectionless communication and 
constant downloading of data, formatting information 
and applet code. 

B4. The application needs to support off-line mobile 
users. 

Mobile computing is becoming more prevalent in the 
work place, therefore, connectivity to a server can not 
be assumed for all user classes. A client server archi- 
tecture allows for the distribution of application logic 
and/or data between the server and client. Replication 
of data and logic is usually necessary for applications 
that are run on portable computers. 
IT Guiding Principles 804 

Gl. The client maintains their applications internally and 
the IT department has the necessary resources, organi- 
zations and processes to maintain a Client Server 25 
application. 

Introduction of a Client Server application to a company's 
production environment can require a great deal of 
change to the Execution, Operations and Development 
architectures required to develop, run and support the 30 
production systems. Before a Client Server application 
is developed, it is important that the client identify how 
a system of this type will fit within the company*s 
strategic technology plan. 
Host Architecture Generation 35 

If ycUents business and technical requirements meet the 
following system characteristics, you should consider an 
application based upon the Host technology generation. 

The following section details the importance of each of 
the statements found in FIG. 9 and should assist you in 40 
identifying the appropriate answer for your specific client 
engagement. 

Existing Architecture and Infrastructure 900 
El. Hie client currently maintains and operates host based 
applications and the IT organization contains personnel 45 
familiar with the development and operation of these 
types of appUcations. 
Few organizations introduce solely host based production 
systems. Usually the infrastructure for this type of 
systems already exists. New development is 
uncommon, typically existing legacy systems need to 
be extended. 

Host systems usually have a mature and stable operations 

enviroimient. Note that mainframe expertise may be 

expensive and in high demand. 
Business Imperatives 902 

Bl. The application will only be xiscd by a dedicated, 

expert user community where a GUI is not needed. 
A dedicated work force with low turnaround, skilled in the 

use of character based 3270 applications, eliminates the 

need for a GUI interface. 
B2. The application requires a high volume of repetitive 

transactions. 

Ihe high degree of processing power provided by main- 65 
frames allows for the development of applications with 
very high performance requirements. 
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B3. The application has a requirement for significant 
batch processing. 

Mainframes are probably still the most powerful plat- 
forms for large scale batch processing. Mature tools 
exist for scheduling, recovery/restart, sorting, merging, 
and moving large sets of data, 

B4. End users can maintain a physical connection to the 
host at all times. 

Physical connection to the host is required for use of the 
applications. Methods of mobile computing with dis- 
tribution of data or bxisiness logic is not possible. 

B5. The application v/ill need to support a large number 
of users (>1000). 

The processing power of today *s mainframe lends itself 
well to the development of large scale, mission critical 
applications with a large user base. 
IP Guiding Principles 904 

Gl. The Client has the resources, organizations and 
processes necessary for the development and operation 
of a Host based application. 

Before a Host based application is developed, it is impor- 
tant that the client identify how a system of this type 
will fit within the company's strategic technology plan, 

G2. Reliance upon a single vendor (IBM) for technology 
solutions is acceptable. 

Selection of a host based architecture inherently locks the 
client into dependence upon one vendor for its tech- 
nology solutions. While IBM is a reputable, stable 
company it may be important to ensure that the client's 
long term business strategy wtU be supported by IBM's 
technology vision and direction. 

G3. Centralized application and data is an acceptable 
strategy. 

A pure host based architecture eliminates the possibility 
of distributing data or business logic to the client. This 
removes some of the application performance benefits 
which can be seen by a distribution strategy, however, 
centralized access to the business logic and business 
data can improve operational stability and lower costs. 
A current trend is to transform mainframe based legacy 
systems into data- and application servers in a multi- 
tiered client/server or Netcentric architcct\u*e. 
Overview of the Frameworks 

One may ask: what frameworks one should use? This 
portion of the specification should help one understand: 
when the various frameworks in SAF can be useful 
how the frameworks are related 
Frameworks Related to Delivery Vehicles 

Most of the frameworks in SAF address various aspects of 
Delivery Vehicle architectures. 

SAF provides access to the user's thought leadership and 
architecture frameworks for Execution, Development and 
Operations environments. Very briefly, SAF covers: 
The Core Execution Architecture frameworks for the 
different architecture generations (Host, Client/Server 
and Netcentric). Most xisers will primarily use the 
Netcentric framework 
The Execution Architecture Extensions. This is a collec- 
tion of the most common delivery vehicles that are built 
for clients. These frameworks extend the core frame- 
works with services specific for a particular delivery 
vehicle. 

The Development Architecture Framework. Should help 
one establish and operate a high-quality development 
environment. 
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The Operations Architecture Framework. Should help one 
establish and operate a high-quality operations envi- 
ronment. 

To learn more about what Dehvery Vehicles are, see the 
DeUvery Vehicle Overview section. This page explains 
the relationships between Architecture Generations, 
Application Styles and Environments. 
Framework Extensions and other Frameworks 

The remaining frameworks in SAF are special purpose 
frameworks that may not directly fit into the current Deliv- 
ery Vehicle definition. 

They may be extensions to the delivery vehicle frame- 
works such as Call Center, Mobile, eCommerce Application 
Framework, Middleware or Component Technologies. 
Framework Recommendations 

The frameworks in SAF address different aspects and 
areas of technology and application architecture. No single 
framework may cover this scope. Depending on the phase of 
one's project and the type of applications one's project will 
deliver, one may need to use different specialized frame- 
works. 

Most implementations today may begin by considering 
the Netcentric Execution framework, then adding extensions 
for the delivery vehicles or specific technologies that your 
project will use. Keep in mind, however, the Development 
and Operations frameworks. Also, remember that some 
architectures will need to be built on multiple frameworks, 
most likely involving the Integration framework to bridge 
between them. 

This section lists all the frameworks currently available in 
SAF, indicates when they may be useful, and how it relates 
to other frameworks: 
Netcentric 

When is it useful? 

This framework constitutes the core of a modem netcen- 
tric and client/server execution architecture. It will help one 
plan and design one's architecture by understanding what 
components a typical netcentric architecture should consist 
of. 

Netcentric Architetcure Framework 
Framework Overview 
Introduction 

The Netcentric Architecture Framework identifies those 
run-time services required when an application executes in 
a Netcentric environment. As shown in FIG. 10, the services 
can be broken down into logical areas: Presentation Services 
1000, Information Services 1002,1004, Communication Ser- 
vices 1006,1008, Communication Fabric Services 1010, 
Transaction Services 1012,1014, Envirorunent Services 
1016,1018, Base Services 1020 and Business Logic 1022, 
1024. This framework is an evolution of the Client Server 
New Age Systems Framework and is useful for technical 
architects involved in the selection, development and 
deployment of technical architectures in a Netcentric envi- 
ronment. More discussion of each of these logical areas is 
provided below. See also FIGS. 11 and 12, which are 
detailed diagrams of the components of the Netcentric 
Architecture Framework found in FIG. 10. 
Netcentric Computing Top 10 Points 

Netcentric computing represents an evolution — it builds 
on and extends, rather than replaces, client/server. 

Netcentric computing has a greater impact on the entire 
biisiness enterprise, hence greater opportunity and risk. 

Definitions of Netcentric may vary. One is about reach 
and content. 

Netcentric is not just electronic commerce; it can impact 
enterprises internally as well. 
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You can begin identifying Netcentric opportunities for 
clients today. 

There are three basic types of Netcentric applications: 

advertise; inquiry; and fully interactive. 
One can underestimate the impact of Netcentric on infra- 
structure requirements. 
Build today's client/server engagements with flexibility to 
extend to Netcentric. 
Netcentric Computing Definition 
' Netcentric Computing also called Netcentric 
Architecture, Netcentric Technology, etc. is an emerging 
architectwe style which expands the reach of computing 
both within and outside the enterprise. Netcentric enables 
sharing of data and content between individuals and appli- 
cations. These applications provide capabilities to publish, 
interact or transact. Netcentric represents an evolution of 
Client/Server which may utilize intemet technologies to 
connect employees, customers, and business partners. 
CHent/Server vs. Netcentric Computing (NCC) 
' NCC is a new style of computing that expands on the 
technological base already provided by traditional client/ 
server systems. Many of the traditional client/server design 
concepts and considerations still apply to NCC. 

The important differences between client/server systems 
and NCC systems arc: 
The way in which the application logic is distributed to 
clients is different in NCC and traditional client/server 
systems. In NCC systems, application logic can be 
I packaged into components and distributed from a 
server machine to a client machine over a network. In 
traditional cfient/server systems, the application logic is 
split between the client and the server on a permanent 
basis; there is no dynamic distribution of application 

35 

The number of tiers in NCC and traditional client/server 
systems is different. NCC extends the traditional two- 
tier client/server architecture to a n-tier architecture. 
Tbe client in NCC systems is different from a client in 

40 traditional client/server systems. The client in a NCC 
system is a standardized universal one; a NCC appli- 
cation can execute within a cHent that can run on 
multiple operating systems and hardware platforms. In 
traditional client/server systems, the client is custom- 

45 made for a specific operating system and hardware 
platform. 

The way in which NCC and traditional cUent/server 
systems can be extended and adapted is different. 
Components enable NCC systems to be adaptable to a 
50 variety of distribution styles, from a "thin client" to a 
*'fat client". In comparison, traditional client/server 
systems, once designed and built, cannot be adapted for 
use on more than one computing style. 
Tiers 

55 Similarly to traditional client/server architectures, Net- 
centric architectures support a style of computing where 
processes on different machines communicate using mes- 
sages. In this style, "client" processes delegate business 
functions or other tasks (such as data manipulation logic) to 

60 one or more server processes. Server processes respond to 
messages from cUents. 

Business logic can reside on both client and server. 
Clients are typically PCs or Workstations with a graphical 
user interface running in a Web browser. Servers arc usually 

65 implemented on UNIX, NT or mainframe machines. 

A key design decision for a client/server system is 
whether it shoidd be two-tiered or multi-tiered and how 
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business logic is distributed across the tiers. In Netcentric 
architectures there is a tendency to move more business 
logic to the server tiers, although "fatter" clients are becom- 
ing more popular with newer technologies such as Java and 
ActiveX. 5 
Two-Tiered Architectures 

Two-tiered architecture describes a distributed application 
architecture in which business applications are split into 
front-ends (clients) and back-ends (servers). Such a model of 
computing began to surface in the late 1980s and is the lo 
prominent configuration in use today by companies which 
have attempted to migrate to client/server based computing. 
Advantages 

At a minimum, a two-tiered client/server architecture 
assumes that an application's presentation logic resides on 15 
the client and its data management logic resides on the 
server. This style of computing became attractive to early 
adopters of client/server because it clearly addresses the 
inadequacies of a character-based interface. That is, it allows 
PC-based chents to introduce a graphical user interface 20 
(GUI) into the appHcation environment. 

Allows rapid development "out-of-the-box" 

Decreased communication overhead because of a direct 
connection (for a small number of users) 

Allows the distribution of the program's logic 
(application, presentation, data management) 
Limitations of Two-Tiered Architecture 

The use of two-tier tools has resulted in a defacto "client- 
heavy" or "fat-client" two-tiered model where the presen- 
tation and application logic resides on the client and data 
management resides on the server. In fact, the use of these 
tools "out-of-the-box" assumes the adoption of such a 
model. Unfortunately, such an architectural model falls short 
of addressing many important issues required of an 
enterprise-wide information architecture. This model of 
computing was actually developed for less-demanding PC 
environments where the database was simply a tool for 
decision support. 
Limitations 

Limited/cost prohibitive Scalability 

Limited availability 

Limited reliability 

Security Deficiencies 

Network/Database bottlenecks 

Low implementation flexibility 

Limited Asynchronous processing 
Three-Hered or Multi-Tiered Architectures 

Three-tiered architecture describes a distributed applica- 50 
tion architecture in which business applications are sepa- 
rated into three logical components: presentation and 
control, application logic, and data management. These 
logical components are "clean layered" such that each runs 
on a different machine or platform, and communicates with 55 
the other components via a network. 

A three-tiered architecture is often enhanced by the inte- 
gration of distributed transaction processing middleware. 
This model of computing is often termed the "enhanced" 
client/server model. Most Netcentric architectures use a 60 
three- or four tiered approach with a web server and poten- 
tially a separate application server layer. 

In the enhanced client/server model, all presentation and 
control logic resides on the client, aU application logic 
resides on multiple back-end application servers, and all 65 
data management logic resides on multiple back-end data- 
base servers. 
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Advantages 

In contrast to mainframe and two-tiered client/server 
computing models, the principle advantage with a three- 
tiered enhanced client/server architecture is that it provides 
the benefits of a GUI application, but also provides a level 
of integrity and reliability found in mainframe centralized 
computing. That is, it will evolve to serve high-volume, 
high-integrity, and high-availabiUty environments. 
Location and implementation transparency — ^The use of a 
transaction manager such as Tuxedo allows for service 
location independence. 
Distribution of logic to optimal resource — Since the 
application and database functions reside on their own 
physical devices, each can be optimally tuned for the 
work they perform. 
Database scaleable on throughput — ^In the enhanced 
three-tiered client/server model, client applications no 
longer connect directly to database servers. Instead, 
only application servers connect to the database serv- 
ers. 

Security over service resources — With the application 
logic residing on back-end application servers, security 
over the applications is made possible at various levels. 

Redundancy and resiliency of services — A major disad- 
vantage prominent in other models of computing is 
"single point of failure. 

Optimization of personnel resources — ^Developers can be 
utilized for specific talents in each tier. 

Allows for asynchronous and standardized messaging — 
The enhanced client/server model is really a superset of 
the RFC-based function shipping model which pro- 
vides features such as asynchronous, event-driven pro- 
gramming. 

Administration, configuration, prioritization — ^The use of 
a transaction manager enables servers to be added, 
removed, or restarted dynamically. This allows for very 
robust, scaleable, and flexible applications. 
Disadvantages 

Three-tier ardiitectures are highly flexible. This flexibility 
comes with the cost of being more complex to implement. 
Limitations 
Additional tool (middleware) selection 
Longer implementation times 

Greater development costs associated with additional tier 
More complex planning 
Additional Skills 
Extra Hardware 

Greater complexity for maintenance, configuration man- 
agement 
Presentation 1000 

Presentation Services enable an application to manage the 
human-computer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 
of processing. FIG. 13 iflustrates several components of the 
Presentation area of the Netcentric Architecture Framework, 

Exemplary products that may be used to enable this 
component include Msual Basic; PowerBuilder; C++; Win- 
dows 3.X/NT/95; X- Windows/Motif; Visual C++; Borland 
Delphi; AC FOUNDATION for FCR 

The products listed as candidates for specific components 
here and below should be used with care. These examples do 
not provide an all-inclusive list, nor do they necessarily 
represent the current market leaders. They are there to 
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provide an example of products that may enable the com- 
ponent services. 
Window System 1300 

Typically part of the operating system, the Window Sys- 
tem Services provide the base functionality for creating and 
managing a graphical user interface (GUI) — detecting user 
actions, managing windows on the display, and displaying 
information in windows. 
Implementation Considerations 

Windowing systems expose their functionality to appli- 
cation programs through a set of application programming 
interfaces (APIs). For the Microsoft windowing platform, 
this API is called Win32. The Win32 API is a documented 
set of over 500 C functions that allow developers to access 
the functionality of the windowing system as well as various 
other operating system functions. While it is possible for 
developers to directly call the Win32 API or its equivalent on 
other platforms using a C language compiler, most business 
application development is done using higher level devel- 
opment languages such as Visual Basic or PowerBuilder 
which make the lower level caUs to the operating systems on 
behalf of the developer. 

Exemplary products that may be used to enable this 
component include Microsoft Windows; Windows 95; Win- 
dows NT; Macintosh OS; Program Manager for OS/2; 
X-Windows/Motif; JavaOS. 
Desktop Manger 502 

Desktop Manager Services implement the desktop meta- 
phor. The desktop metaphor as the name suggests is a style 
of user interface that tries to emulate the idea of a physical 
desktop allowing you to place documents on the desktop, 
launch applications by clicking on a graphical icon, or 
discard files by dragging them onto a picture of a waste 
basket. Most Window Systems contain elementary Desktop 
Manager functionahty (e.g., the Windows 95 desktop), but 
often more user friendly or functional Desktop Manager 
Services are required. 

Microsoft Windows 95 Task Bar; Norton Navigator; Xerox 
Tabworks; Starfish Software Dashboard 
Product Considerations 

Exemplary products that may be used to enable this 
component include: 

Microsoft Windows 95 task bar — provides a launch bar 
which allows users to access recently used documents, 
launch applications, or switch between active applica- 
tions. The Windows 95 desktop and launch bar are 
programmable allowing users to extend and customize 
the desktop manager for their specific application. For 
example, the desktop can be extended with icons or 
Start Menu options for creating a new customer 
account or finding an order. 

Norton Navigator — provides multiple virtual desktops, 
enhanced file management including direct FTP 
connectivity, long file name support for some 16-bit 
applications, file un-erase, and other features; targeted 
at users who often interact with the Windows 95 
desktop. 

Xerox Tabworks — ^presents the user with a notebook 
metaphor for application and document access; allows 
creation of tabbed sections which contain related files 
(e.g., Winston Account or New Product Launch) for 
easier access. 

Starfish Software Dashboard — a desktop utlfity designed 
to simplify application and system management; pro- 
vides quick launch buttons, system resource gauge, 
drag-and-drop printing and faxing, calendar, etc. 
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Form 1304 

Form Services enable applications to use fields to display 
and collect data. Afield may be a traditional 3270-style field 
used to display or input textual data, or it may be a graphical 
5 field such as a check box, a list box or an image. Form 
Services provide support for 

Display — support the display of various data types (e.g., 
text, numeric, date, etc.) in various formats (e.g., American/ 
European date, double-byte characters, icons, etc.) 

Input/Valklation — enable applications to collect informa- 
tion fi-om the user, edit it according to the display options, 
and perform basic validation such as range or format checks. 

Mapping Support — eliminate the need for applications to 
communicate directly with the windowing system; rather, 
applications retrieve or display data by automatically copy- 
ing the contents of a window's fields to a copybook structure 
in memory. These Services may also be used to automate the 
merging of application data with pre-defined electronic form 
^ templates. 

Field Interaction Management — coordinate activity 
across fields in a window by managing field inter- 
dependencies and invoking application logic based on the 
state of fields and user actions. For example, the Field 

25 Interaction Manager may disable the "OK" button until all 
required input fields contain valid data. These services 
significantly reduce the application logic complexity inher- 
ent to an interactive windowed interface. 
Implementation Considerations 

30 In traditional client/server applications, Forms are win- 
dows that contain widgets (text fields, combo -boxes, etc.) 
and business logic. Form development tools such as Msual 
Basic, PowerBuilder, etc. allow the Form designer to specify 
page layout, entry fields, business logic, and routing of 

35 forms. From a developers perspective, these products typi- 
cally expose Form and control handling functionality as a set 
of proprietary or product specific APIs. 

In addition to the traditional tools (e.g., Visual C++, 
Visual Basic, PowerBuilder), Netccntric technologies have 

40 introduced new tools that can be used to develop Forms. For 
example, a developer can use Symantec Visual Cafe to 
create a Java application that will execute directly on the 
users desktop without any interaction with a browser. 

Today most Netcentric applications are Web based and are 
launched from the Web browser. Additionally, one is now 
beginning to see other types of Netcentric solutions. For 
example, Ejo^^^SpJa Netcentric application located on the 
users macliin^it"' relies on the Internet to deliver stock 
prices, news headings, sports updates, etc. to the user. 

50 However, it is not launched from the Web browser — it is its 
own application. In the future there will be more Netccntric 
applications that use this approach for delivering informa- 
tion. 

Product Considerations 

WhaX level of technical support, documentation, and 
training is required to ensure the productivity of developers? 

The extent of support (on-site, phone, bulletin board, 
world-wide, etc.), quality of doomientation, and availability 
gg and location of education/training should be considered. 
What functions are required in the control set? 
At the minimum a tool should support basic widgets (push 
buttons, list boxes, etc.), window styles, (multi-window, 
multi-document, paned-window), and menu styles, along 
65 with validation and inter-application communication. Con- 
sideration should also be given as to the extensibility of the 
toolset via add-ons and third party products. 
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Can the tool be used for both prototyping and GUI 
design? 

The ability to use a single tool for both prototyping and 
GUI design will reduce the development learning curve. 
One should also consider how well the tool integrates will all 
other development tools. 

What platform(s) are supported? 

The platform(s) that must be supported, i.e., MS-DOS, 
Windows, IBM OS/2, UNIX, or UNIX Motif, is an impor- 
tant consideration, as are any hardware restrictions. 

What type of learning curve is associated with the tool? 

Developers using the product should be able to become 
productive quickly. Factors which reduce the learning curve 
include an easy to learn and intuitive interface, thorough and 
clear documentation, and on-line help. 

If the tool is also going to be used for application 
development, how well does the tool perform during pro- 
duction? 

Computational, network, data retrieval, and display 
speeds differ for products. Factors to consider are whether 
the application wiU consist of heavy data entry, transaction 
processing, or a large user base. 

How much does the tool cost? 

Product components, maintenance agreements, upgrades, 
run-time licenses, and add-on packages should be consid- 
ered. 

Does the product integrate with other tools and/or support 
other tools in the development and execution environments? 

It is important to determine how well the product inte- 
grates with other design and development tools, presentation 
services (graphics, miilti-media, etc.), data access services 
(databases and database API libraries), distribution services 
(distributed TP monitor), transmission services (SNA, 
HLLAPI, etc.), data dictionary, desktop applications, and 
programming languages for call-out/call-in. Additional con- 
sideration should be given to add-on and third-party 
products/enhancements such as specialized widgets, report 
writers and case tools. 

WiU the tool be used with a large development team? 

If the development team is more than 5 people, a tool 
should provide support for multiple developers. This support 
includes features such as object check-in/check-out, a cen- 
tral design repository for the storage of appUcation objects 
and user interface definitions, and version control. 
Additionally, the development team should be able to 
cleanly divide the application(s) into pieces which can be 
worked on by multiple people. 

What protocols are used to communicated with the data- 
base? 

Important considerations include the supported databases 
and protocols used to communicated with the databases. The 
tool must support the selected database. Additionally, if the 
database selection may change, it is important that the tool 
have the ability to support other databases with minimal 
impact on the application development. Native database 
interfaces tend to have better performance than open stan- 
dards such as ODBC. 

Will the design tool be used for programming of client 
applications? What programming language is supported? 

If the design tool is used for programming, there are 
several features of a tool which must be considered. These 
features can have an impact on the productivity of 
programmers, performance of the applications, skill sets 
required, and other tools required for development. These 
features include: 

What programming language is supported? Is the pro- 
gramming language interpretive or compiled? Is it 
object oriented or structured procedural language? 
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Does the tool support programming extensions to 

Dynamic Link Libraries? 
What are the debugging capabilities of the tool? 
Is the tool scalable? 
5 The tool should be scalable to support growth in appli- 
cation size, users, and developers. 

Exemplary products that may be used to implement this 
component include JetForms JetForm Design; Lotus Forms; 
Visual Basic. 

10 JetForms JetForm Design — ^provides tools to design, fill, 
route, print and manage electronic forms, helping orga- 
nizations reduce costs and increase efficiency by auto- 
mating processing of forms across local and wide area 
networks as well as the Internet. Lotus Forms — Lotus 
15 Development Corporations electronic forms software 
provides tools to design, route and track forms to 
automate business processes for the workgroup or the 
extended enterprise. Lotus Forms is designed to run 
with Lotus Notes or as a standalone appUcation. It is 
20 comprised of two parts: Forms Designer, an 
application-development version, and Forms Filler, a 
runtime version for users. Visual Basic — a develop- 
ment tool that provides a comprehensive development 
environment for building complex appUcations. 
25 User Navigation 1306 

User Navigation Services provide a user with a way to 
access or navigate between functions within or across appli- 
cations. Historically, this has been the role of a text-based 
menuing system that provides a list of applications or 
30 activities for the user to choose ftom. 

Client/server technologies introduced new navigation 
metaphors. A method for allowing a user to navigate within 
an application is to list available functions or information by 
means of a menu bar with associated pull-down menus or 
35 context-sensitive pop-up menus. This method conserves 
screen real-estate by hiding functions and options within 
menus, but for this very reason can be more difficult for first 
time or infrequent users. This point is important when 
implementing electronic commerce solutions where the tar- 
40 get customer may use the application only once or very 
infrequently (e.g., purchasing auto insurance). 

Additionally, client/server development tools such as 
Visual Basic and PowerBuilder do not provide specific 
services for graphical navigation, but the effect can be 
45 recreated by selecting (Le., clicking on) graphical controls, 
such as picture controls or iconic push-buttons, programmed 
to launch a particular window. 

A major advantage of the graphical user interface is the 
fact that it allows multiple windows to be open at one time. 
50 Implementation Considerations 

Is there a need to manage multiple instances of a window 
object? 

Windows Interaction Manager provides the application 
with facilities to open multiple instances of the same win- 
55 dow. This component provides an option parameter that will 
let the application developers enable or disable the ability to 
open the same window with the same key data (that is, a 
duplicate instance). 

Do you need to pass messages between windows? 
60 Windows Interaction Manager provides the facility to 
pass messages between windows within one application. 
This allows one window to trigger an event/action on 
another related window. 

Do m\iltiple applications need to pass messages between 
65 each other? 

Windows Interaction Manager provides the facility to 
pass messages between windows from different applications 
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residing on the same machine. This allows one window to 
trigger an event/action on an related window when certain 
actions (user or environment) occur. 

If information needs to be shared between applications on 
different machines, Window Interaction Management can- 
not be used. This type of data sharing requires a special 
architecture component called Commimication, which is 
more network orientated. 

Is there a need for object registration/de-registration? 

Windows Interaction management allows the application 
to control and manage the opening and closing of multiple 
windows by — maintainiag the parent-child relationship, 
controlling multiple instances of similar windows, maintain- 
ing key data-window relationship. This allows the user to 
work in a controlled and, well managed, environment. 
Web Browser 1308 

Web Browser Services allow users to view and interact 
with applications and documents made up of varying data 
types, such as text, graphics, and audio. These services also 
provide support for navigation within and across documents 
no matter where they are located, through the use of links 
embedded into the document content. Web Browser Services 
retain the link connection, i.e., document physical location, 
and mask the complexities of that connection from the user. 
Web Browser services can be further subdivided into: 
Browser Extension, Form, and User Navigation, 

Parlez-Vous Internet? 
The Elements of Web Style 

Language philosopher Benjamin Whorf once said, "We 
dissect nature along lines laid down by our native language. 
Language is not simply a reporting device for experience, 
but a defining framework for it." This notion is especially 
true when applied to the World Wide Web. The evolution of 
the Web from a rigid, text-centric village to an elastic, 
multimedia-rich universe has been driven by modifications 
to the languages behind it. The Internet is at a crucial point 
in its development as a number of enhancements for extend- 
ing Web technology come under scrutiny by Internet stan- 
dards groups. These enhancements will ultimately push the 
Web into the realms of distributed document processing and 
interactive multimedia. 

SGML: in the Beginning . . . 

Although the World Wide Web was not created until the 
early 1990s, the language behind it dates back to the genesis 
of the Internet in the 1960s. Scientists at IBM were working 
on a Generalized Markup Language (GML) for describing, 
formatting, and sharing electronic documents. Markup 
refers to the practice in traditional pubhshing of annotating 
manuscripts with layout instructions for the typesetters. 

In 1986, the International Standards Organization (KG) 
adopted a version of that early GML called Standard Gen- 
eralized Markup Language (SGML). SGML is a large and 
highly -sophisticated system for tagging documents to ensure 
that their appearance will remain the same regardless of the 
type of platform used to view them. Designers iise SGML to 
create Docxmient lype Definitions (DTDs), which detail 
how tags (also known as format codes) are defined and 
interpreted within specified documents. These tags can be 
used to control the positioning and formatting of a docu- 
ment's text and images. SGML is used for large, complex, 
and highly-structured documents that are subject to frequent 
revisions, such as dictionaries, indexes, computer manuals, 
and corporate telephone directories. 

HTML: SGML for Dummies? 

While creating the World Wide Web in the eariy 1990s, 
scientists at CERN discovered that in spite of its power and 
versatility, SGML's sophistication did not allow for quick 
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and easy Web publishing. As a result, they developed 
HyperText Maricup Language (HTML), a relatively simple 
application of SGML. This simplicity has conU-ibuted to the 
exponential growth of the Web over the last few years. 

J HTML files are written in plain text and can be ere atcd iising 
any text editor from the most robust Web page authoring 
software (such as Microsoft's FrontPage or Sausage Soft- 
ware's HotDog) to the anemic Notepad utility included with 
Microsoft's Windows operating system. 
As with many languages, HTML is in a state of constant 

10 evolutioa The World Wide Web Consortium W3C oversees 
new extensions of HTML developed by both software 
companies (such as Microsoft and Netscape 
Communications) and individual Web page authors and 
ensures that each new specification is fully-compatible with 

25 previous ones. Basic features supported by HTML include 
headings, lists, paragraphs, tables, electronic forms, in-line 
images (images next to text), and hypertext links. Enhance- 
ments to the original HTML 1.0 specification include 
banners, the applet tag to support Java, image maps, and text 
flow around images. 

The W3C also approved the specification for version 4.0 
of HTML(http://www.w3.org/TR/REC-html40).This speci- 
fication builds upon earlier iterations of HTML by enabling 
Web authors to include advanced forms, in-Une frames, and 
enhanced tables in Web pages. HTML 4.0 also allows 

25 authors to publish pages in any language, and to better 
manage differences in language, text direction, and character 
encoding. 

Perhaps most significantly, HTML 4.0 increases authors* 
control over how pages are organized by adding support for 

30 Cascading Style Sheets CSS Style sheets contain directions 
for how and where layout elements such as margins, fonts, 
headers, and links are displayed in Web pages. With CSS, 
authors can use programming scripts and objects to apply 
midtiple style sheets to Web pages to create dynamic con- 

35 tent. CSS can also be used to centralize control of layout 
attributes for multiple pages within a Web site, thus avoiding 
the tedious process of changing each page individually. 
Dynamic HTML: Dyn-o-mite! 

HTML's simplicity soon began to limit authors who 
demanded more advanced multimedia and page design 
capabilities. Enter Dynamic HTML DHTML As an exten- 
sion of HTML, DHTML allows Web pages to funaion more 
like interactive CD-ROMs by responding to user-generated 
events. DHTML allows Web page objects to be manipulated 
after they have been loaded into a browser. This enables 

^5 users to shun plug-ins and Java applets and avoid 
bandwidth-consunung return trips to the server. For 
example, tables can expand or headers can scurry across the 
page based on a user's mouse movements. 

Unfortunately, the tremendous potential offered by 

50 DHTML is marred by incompatible standards. At the heart 
of the DHl^L debate is a specification called the Document 
Object Model DOM, The DOM categorizes Web page 
elements — including text, images, and links — as objects and 
specifies the attributes that are associated with each object. 

55 The DOM makes Web document objects accessible to 
scripting languages such as JavaScript and YisualBasic 
Script (VBScript), which can be used to change the 
appearance, location, and even the content of those objects 
in real-time. 

Microsoft's Internet Explorer 4.0 supports a W3C "Work- 
^ ing Draft" DOM specification that uses the CSS standard for 
layout control and Web document object manipulation. In 
contrast, Netscape's implementation of DHTML in Com- 
municator 4.0 uses a proprietary "Dynamic Layers" tag, 
which assigns multiple layers to a page within which objects 
65 are manipulated. As a result, Web pages authored using 
either version of DHTML may not be viewed properly using 
the other's browser XML: X marks the spot 
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HTML 4.0 and Dynamic HTML have given Web authors 
more control over the ways in which a Web page is dis- 
played. But they have done little to address a growing 
problem in the developer community: how to access and 
manage data in Web documents so as to gain more control 5 
over document structure. To this end, leading Internet devel- 
opers devised Extensible Markup Language (XML), a 
watered-down version of SGML that reduces its complexity 
while maintaining its flexibility. Like SGML^ XML is a 
meta-language that allows authors to create their own cus- 10 
tomized tags to identify different types of data on their Web 
pages. In addition to improving document structure, these 
tags will make it possible to more effectively index and 
search for information in databases and on the Web. 

XML documents consist of two parts. The first is the 15 
document itself, which contains XML tags for identifying 
data elements and resembles an HTML document. The 
second part is a DTD that defines the document structure by 
explaining what the tags mean and how they should be 
interpreted. In order to view XML documents, Web brows- 20 
ers and search engines will need special XML processors 
called "parsers." Currently, Microsoft's Internet Explorer 
4.0 contains two XML parsers: a high-performance parser 
written in C++ and another one written in Java. 

A number of vendors plan to use XML as the underlying 25 
language for new Web standards and applications. Microsoft 
uses XML for its Channel Definition Format, a Web-based 
"push" content delivery system included in Internet Explorer 
4.0. Netscape will use XML in its Meta Content Framework 
to describe and store metadata, or collections of information, 30 
in forthcoming versions of Communicator. XML is currently 
playing an important role the realm of electronic commerce 
via the Open Financial Exchange, an application developed 
by Microsoft, Intuit, and CheckFree for conducting elec- 
tronic financial transactions. Similarly, HL7, a healthcare 35 
information systems standards organization, is using XML 
to support electronic data interchange EDI of clinical, 
financial, and administrative information (http:// 
www.mcis.dTike.edu/standards/HL7/sigs/sgml/index.html). 
Meet Cousin VRML 40 

In 1994, a number of Internet thought leaders, including 
Tim Berners-Lee — the "father" of the Web — met to deter- 
mine how they could bring the hot, new technology known 
as virtual reality VR to the Web. VR refers to the use of 
computens to create artificial and navigable 3-D worlds 45 
where users can create and manipulate virtual objects in real 
time. This led to the creation of Virtual Reality Modeling 
Language (VRML — pronounced "ver-mul"). VRML is tech- 
nically not a markup language because it uses graphical 
rather than text-based file formats. 50 

In order to create 3-D worlds and objects with VRML, 
users need a VRML editor such as Silicon Graphics' Cosmo 
Worlds (http://cosmo.sgi.com/products/studio/worlds). To 
view VRML content, users need either a VRML browser or 
a VRML plug-in for standard HTML browsers. Leading 55 
VRML plug-ins include Cosmo Player from Silicon Graph- 
ics (http://vrml.sgi.com/cosmoplayer), Liquid Reality from 
Microsoft's DimensionX subsidiary (http:// 
www.microsoft.com/dimensionx), OZ Virtual from OZ 
Interactive (http://www.oz.com/ov/main__bot.html), and 60 
WorldView from Intervista (http://www.intervista.com/ 
products/worldview/index.html), These plug-ins can typi- 
cally be downloaded for free from the Web. 

VRML is capable of displaying static and animated 
objects and supports hyperlinks to multimedia formats such 65 
as audio clips, video files, and graphical images. As users 
maneuver through VRML worlds, the landscape shifts to 
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match their movements and give the impression that they are 
moving through real space. The new VRML 2.0 specifica- 
tion finalized in August 1996 intensifies the immersive 
experience of VR worlds on the Web by enabling users to 
interact both with each other and with their surroundings. 
Other new features supported by VRML 2.0 include richer 
geometry description, background textures, sound and 
video, multilingual text, Java applets, and scripting using 
VBScript and JavaScript. VRML will become a significant 
technology in creating next-generation Internet application 
as the language continues to matxire and its availability 
increases. 

The Future: Give us a Big SMIL 

The Web has come a long way since the codification of 
HTML 1,0. It has moved from simple text-based documents 
that included headings, bulleted lists, and hyperlinks to 
dynamic pages that support rich graphic images and virtual 
reality. So what next for the Web? The answer resides in a 
Synchronized Multimedia Integration Language (SMIL), a 
new markup language being developed by the W3C. SMIL 
will allow Web authors to deliver television-like content 
over the Web using less bandwidth and a simple text editor, 
rather than intricate scripting. 

SMIL is based on XML and does not represent a specific 
media format. Instead, SMIL defines the tags that link 
different media types together. The language enables Web 
authors to sort multimedia content into separate audio, 
video, text, and image files and streams which are sent to a 
user's browser. The SMIL tags then specify the "schedule" 
for displaying those components by determining whether 
they should be played together or sequentially. This enables 
elaborate multimedia presentations to be created out of 
smaller, less bandwidth-consuming components. 
Implementation Considerations 

Many features sudi as graphics, frames, etc. supported by 
Web Browsers today were not available in initial releases. 
Furthermore, with every new release die functionality sup- 
ported by Web Browsers keeps growing at a remarkable 
pace. 

Much of the appeal of Web Browsers is the ability to 
provide a universal client that will offer users a consistent 
and familiar iiser interface from vMch many types of 
applications can be executed and many types of documents 
can be viewed, on many types of operating systems and 
machines, as well as independent of where these applica- 
tions and documents reside. 

Web Browsers employ standard protocols such as Hyper- 
text Transfer Protocol (HTTP) and File Transfer Protocol 
(FTP) to provide seamless access to documents across 
machine and network boundaries. 

The distinction between the desktop and the Web Browser 
narrowed with the release of Microsoft IE 4.0, which 
integrated Web browsing into the desktop, and gave a user 
the ability to view directories as though they were Web 
pages. Web Browser, as a distinct entity, may even fade 
away with time. 

Exemplary products that may be used to implement this 
component includes Netscape Navigator; Netscape Commu- 
nicator; Microsoft Internet Explorer; Netscape LivcWire; 
Netscape Live Wire Pro; Symantec Visual Cafe; Microsoft 
Front Page; Microsoft Visual J++; IBM VisualAge. 
Execution Products 

Netscape Navigator or Communicator — one of the origi- 
nal Web Browsers, Navigator currently has the largest 
market share of the installed browser market and strong 
developer support. Communicator is the newest version 
with add-on collaborative functionality. 
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Microsoft iQtemet Explorer (IE) — a Web Browser that is 
tightly integrated with Windows and supports the major 
features of the Netscape Navigator as well as 
Microsoft's own ActiveX technologies. 
Development Products 5 

Web Browsers require new or at least revised develop- 
ment tools for working with new languages and standards 
such as HTML, ActiveX and Java. Many browser content 
development tools are available. The following arc several 
representative products: 

Netscape liveWire and liveWire Pro — visual tool suite 
designed for building and managing complex, dynamic Web 
sites and creating live online applications. 

Symantec \%ual Cafe — the first complete Rapid Appli- 
cation Development (RAD) environment for Java; it allows 
developers to assemble complete Java applets and apphca- 
tions from a hbrary of standard and third party objects. 
Visual Cafe also provides an extensive set of text based 
development tools. 
Microsoft FrontPage — Web site management tool that 20 
supports web page creation, web site creation, page and 
hi^ management and site administration. 
Microsoft Msual J+^ — a product similar to Visual C++, 
VJ++ allows the construction of Java and ActiveX 
appUcations through an integrated graphical develop- 25 
ment environment. 
IBM MsualAge for Java — a product similar to VisualAge 
for Smalltalk, VJ++ allows the construction of Java 
applications through an integrated graphical develop- 
ment environment. It supports JavaBeans. Used by 30 
Eagle team for the Eagle JavaBeans reference apphca- 
tion. 

Browser Extension 1310 

Browser Extension Services provide support for execut- 
ing different types of applications from within a Browser. 35 
These applications provide functionality that extend 
Browser capabilities. The key Browser Extensions are: 

Plug-in — a term coined by Netscape, a plug-in is a 
software program that is specifically written to be executed 
within a browser for the purpose of providing additional 40 
functionality that is not natively supported by the browser, 
such as viewing and playing unique data or media types. 
Typically, to use a phig-in, a user is required to download 
and install the Plug-in on his/her client machine. Once the 
Plug-in is installed it is integrated into the Web browser. The 45 
next time a browser opens a Web page that requires that 
Plug-in to view a specific data format, the browser initiates 
the execution of the Plug-in. Until recently Plug-ins were 
only accessible from the Netscape browser. Now, other 
browsers such as Microsoft's Intemet Explorer are begin- 50 
ning to support Plug-in technology as well. Also, Plug-ins 
written for one browser will gpnerally need to be modified 
to work with other browsers. Plug-ins are also operating 
system dependent. Therefore, separate versions of a Plug-in 
may be required to support Windows, Macintosh, and Unix S5 
platforms. 

Helper Application/Viewer — ^is a software program that is 
launched from a browser for the purpose of providing 
additional functionality to the browser. The key differences 
between a helper application or sometimes called a viewer 60 
and a plug-in are: 

How the program is integrated with the Web browser — 
unlike a plug -in, a helper application is not integrated 
with the Web Browser, although it is launched from a 
Web browser. A helper application generally runs in its 65 
own window, contrary to a plug-in which is generally 
integrated into a Web page. 
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How the program is installed — ^like a plug-in, the user 
installs the helper application. However, because the 
helper application is not integrated with the browser, 
the user tends to do more work during installation 
specifying additional information needed by the 
browser to launch the helper application. 
How the program is initiated — the user tends to initiate 
the launching of the helper application, unlike a plug-in 
where the browser does the initiation. 
From where the program is executed — (he same helper 
application can be executed from a variety of browsers 
without any updates to the program, unbke a plug-in 
which generally needs to be updated for specific brows- 
ers. However, helper applications are still operating 
system dependent. 
Java applet — a program written in Java that runs within or 
is laimched from the client's browser. This program is 
loaded into the client device's memory at runtime and then 
unloaded when the application shuts down. A Java applet 
can be as simple as a cool animated object on an HTML 
page, or can be as complex as a complete windows appU- 
cation mnning within the browser. 

ActiveX control — is also a program that can be run within 
a browser, from an application independent of a browser, or 
on its own. ActiveX controls arc developed using Microsoft 
standards that define how re-usable software components 
should be built. Within the context of a browser, ActiveX 
controls add functionality to Web pages. These controls can 
be written to add new features like dynamic charts, anima- 
tion or audio. 

Implementation Considerations 

Viewers and plug-ins are some of the most dynamic 
segments of the browser market due to quickly changing 
technologies and companies. What was yesterday a plug-in 
or a viewer add-on often becomes a built-in capability of the 
browser in its next release. 

Exemplary products that may be used to implement this 
component include Real Audio Player; VDOLive; Macro- 
media Shockwave; Internet Phone; Web 3270, 

Real Audio Player — a plug-in designed to play audio and 
video in real-time on the Internet without requiring to 
download the entire audio file before you can begin 
listening, or a video file before you can begin viewing. 
Macromedia Shockwave — a plug-in used to play back 
complex multimedia documents created using Macro- 
media Director or other products. 
Intemet Phone — one of several applications which allow 
two-way voice conversation over the Intemet, similar 
to a telephone call. 
Web3270 — a plug-in from Information Builders that 
allows mainframe 3270-based applications to be 
viewed across the Intemet from within a browser. The 
Web3270 server provides translation services to trans- 
form a standard 3270 screen into an HTML-based 
form. Interest in Web3270 and similar plug-ins has 
increased with the Internets ability to provide custom- 
ers and trading partners direct access to an organiza- 
tions applications and data. Screen scraping plug-ins 
can bring legacy applications to the Internet or intranet 
very quickly. 
Form 1312 

Like Form Services outside the Web Browser, Form 
Services within the Web Browser enable appUcations to use 
fields to display and collect data. The only difference is the 
technology used to develop the Forms. The most common 
type of Forms within a browser are Hypertext Markup 
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Language (HTML) Forms. The HTML standard includes 
tags for informing a compliant browser that the bracketed 
information is to be displayed as an editable field, a radio 
button, or other form-type control. Currently, HTML brows- 
ers support only the most rudimentary forms — basically 
providing the presentation and collection of data without 
validation or mapping support When implementing Forms 
with HTML, additional services may be required such as 
client side scripting (e.g., VB Script, JavaScript). 

Additionally Microsoft has introduced ActiveX docu- 
ments which allow Forms such as Word docimients. Excel 
spreadsheets, Visual Basic windows to be viewed directly 
from Internet Explorer just like HTML pages. 

Different technologies may be used to create Forms that 
are accessible outside of the browser from those that are 
accessible within the browser. However, with the introduc- 
tion of ActiveX docuiments these differences are getting 
narrower. 

Exemplary products that may be used to implement this 
component include JetForms JetForm Design; Lotus Forms; 
Visual Basic; Front Page. 

FrontPage — ^Web site management tool that supports web 
page creation, web site creation, page and link man- 
agement and site administration. 
User Navigation 1314 

Like User Navigation Services outside the Web Browser, 
User Navigation Services within the Web Browser provide 
a user with a way to access or navigate between functions 
within or across applications. These User Navigation Ser- 
vices can be subdivided into three categories: 

Hyperlink — the Internet has popularized the use of under- 
Uned key words, icons and pictures that act as links to further 
pages. The hyperlink mechanism is not constrained to a 
menu, but can be used anywhere within a page or document 
to provide the user with navigation options. It can take a user 
to another location within the same document or a different 
document altogether, or even a different server or company 
for that matter. There are three types of hyperlinks: 

Hypertext is very similar to the concept of Context 
Sensitive Help in Windows, where the reader can move from 
one topic to another by selecting a highlighted word or 
phrase. 

Icon is similar to the hypertext menu above, but selections 
are represented as a series of icons. The HTML standard and 
popular browsers provide hypetlinking services for non-text 
items such as graphics. 

Image Map is also similar to the hypertext menu above, 
but selections are represented as a series of pictures. A 
further evolution of the image map menu is to display an 
image depicting some place or thing (e.g., a picture of a bank 
branch with tellers and loan oflBcers). 

Customized Menu — a menu bar with associated pull- 
down menus or context-seositive pop-up menus. However, 
as mentioned earlier this method hides functions and options 
within menus and is-difi&cult for infrequent users. Therefore, 
it is rarely used directly in HTML pages, Java applets or 
ActiveX controls. However, this capability might be more 
applicable for intranet environments where the browsers 
themselves need to be customized (e.g., adding custom 
puU-down menus within Internet Explorer) for the organi- 
zations specific business applications. 

Virtual Reality — A virtual reality or a virtual environment 
interface takes the idea of an image map to the next level by 
creating a 3-dimensional (3-D) environment for the user to 
walk around in. Popularized by PC games like Doom, the 
virtual environment interface can be used for business 
applications. Imagine walking through a shopping mall and 
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into and around virtual stores, or flying around a 3-D virtual 
resort complex you are considcriog for a holiday. 

To create sophisticated user navigation interfaces such as 
these requires additional architectural services and lan- 
5 guages. The Mrtual Reality Modeling Language (VRML) is 
one sudi language gaining in popularity. 
Implementation Considerations 

The hyperlink metaphor makes it possible for the user to 
jump from topic to topic instead of reading the document 
jQ from beginning to end. For many types of applications, this 
can create a more user-friendly interface, enabling the user 
to find information faster. 

An image map menu can be useful where all users share 
some visual model for how business is conducted, and can 
j5 be very engaging, but also painfully slow if even a moderate 
speed communications connection is required. Additional 
Image Map Services are required to map the location of user 
mouse clicks within the image to the corresponding page or 
window which is to be launched. 
20 Exemplary products that may be used to implement this 
component include Silicon Graphics Open Inventor; 
VREAM VRCreator; DimensionX liquid Reality, 

There are many toolkits and code libraries available to 
speed development of applications utilizing Reality services. 
25 Below are some representative products: 

Silicon Graphics Open Inventor — an object-oriented 3-D 
toolkit used to build interactive 3-D graphics using 
objects such as cameras, lights and 3-D viewers; pro- 
vides a simple event model and animation engine. 
30 VREAM VRCreator — a toolkit for building interactive 
virtual reality environments; supports gravity, 
elasticity, and throw-ability of objects, textured and 
colored 3-D objects and construction of networked 
multi-participant worlds. Provides support for ActiveX. 
35 DimensionX Liquid Reality — VRML 2.0 platform writ- 
ten in Java, which provides both a viewer for viewing 
VRML content and a toolkit of Java classes for creating 
powerful 3-D applications. It supports more than 250 
classes for 3-D content creation. 
40 Report and Print 1316 

Report and Print Services support the creation and 
on-screen previewing of paper or photographic documents 
which contain screen data, application data, graphics or 
images. 

45 Implementation Considerations 

Printing services must take into consideration varying 
print scenarios common in Netcentric environments, includ- 
ing: varying graphics/file types (Adobe .PDF, .GIF, JPEG), 
page margins and breaks, HTML constructs including tables 

50 and frames, headers/titles, extended character set support, 
etc. 

Is there a need for reporting or decision support? 
Use report writers when you need to transform user data 
into columnar reports, forms, or mailing lists that may 
55 require sophisticated sorting and formatting facilities. This 
generally occurs for two reasons. Hie first is building 
"production reports*' (Le., reports that are built once and then 
used repeatedly, generally on a daily/weekly/monthly basis). 
The second is ad hoc reporting and decision support. Prod- 
60 ucts targeted at one or the other use will have different 
facilities, (source is market research) 
Is there a need to ease access to corporate data? 
Use report writers when users require easy and quick 
access to corporate data. Since developers can deliver 
65 reports as run-time applications, users are shielded from 
having to leam complicated databases in order to access 
information. All a user has to do to retrieve the data is click 



06/17/2004, EAST Version: 1.4.1 



us 6,636,242 B2 

47 48 

on an icon to launch a report. Because these run-time Supported report types 

applications are smaller than normal applications, they Aggregate functions. 

launch faster and require very little training to operate. Is the intention to create production reports or facilitate 

(source is market research) end user queries? 

Product Considerations 5 Ease of use will be of major importance for end user query 

Buy vs. Build and decision support type applications. In contrast, func- 

Thcre are numerous packaged controls on the market tionality that allows for the implementation of complex 

today that support basic report and print capability, reporting requirements wiU outweigh ease of use for appH- 

However, a carefiil evaluation of both functions and features cations whose objective is creating production reports, 

and vendor viability must be completed before a decision lo Direct Manipulation 1318 

can be made. Architects must additionally be sure to evalu- Direct Manipulation Services enable applications to pro- 

ate that controls will support all required environments, are vide a direct manipulation interface (often called "drag & 

small in size and extensible as requirements demand. drop"). A direct manipulation interface allows xisers to 

How important is performance? manage multiple "application objects" by manipiilating 

In general, performance of data access and printing should 15 visual representations of those objects. For example, a user 

be considered. Some typical benchmark tests include table may sell stock by dragging "stock" icons out of a "portfolio^' 

scan, single-table report, joined table report, and mailing icon and onto a "trading floor" icon. Direct Manipiilation 

label generation times, (source is market research) Services can be further divided as follows: 

What is the budget? Display: These services enable applications to represent 

Per developer costs as well as run time licensing fees, 20 application objects as icons and control the display charac- 

maintenance costs, support fees, and upgrade charges should teristics (color, location, etc.) of these icons, 

be considered. Input/Validation: These services enable applications to 

Do I have another component that satisfies this require- invoke validation or processing logic when an end user "acts 

ment? on" an application object . "Acting on" an obj ect may include 

Many databases and application development tools are 25 single clicking, double clicking, dragging, or sizing, 

shipped with built in or add-on report writing capability. Input Device 1320 

However, stand-alone report writers: (1) are more powerful Detect user input from a variety of input technologies (i.e. 

and flexible, especially when dealing with multiple data pen based, voice recognition, touch-screen, mouse, digital 

sources and a wide variety of formats; (2) can retrieve camera, etc.). 

information from more data sources than the bundled report 30 Implementation Considerations 

writers and can create reports from several data sources Voice response systems are used to provide prompts and 

simultaneously; (3) excel in ease of use, both in designing responses to users through the use of phones. Voice response 

and generating reports; (4) offer better tools and more systems have scripted call flows which guide a caller 

predefined reports; and (5) have faster engines, (source is through a series of questions. Based on the users key pad 

market research)s 35 response, the voice response system can execute simple 

Does the product integrate with the existing or proposed calculations, make database calls, call a mainframe legacy 

architecture? application or call out to a custom C routine. Leading voice 

It is important to consider how well a product integrates response system vendors include VoiceTek and Periphonics, 

with desktop tools (word processing, spreadsheet, graphics Voice recognition systems are becoming more popular in 

etc.) and appUcation development programs. These items 40 conjunction with voice response systems. Users are able to 

can be used to extend the capabilities of the reporting speak into the phone in addition to using a keypad. Voice 

package. recognition can be extremely powerful technology in cases 

What databases does the product support? where a key pad entry would be limiting (e.g., date/time or 

A product should support the most widely used PC file location). Sophisticated voice recognition systems have 

formats and Client/Server databases. It may be necessary to 45 been built which support speaker-independence, continuous 

consider the type of support. For example, native database speech and large vocabularies, 

interfaces tend to have better performance than open stan- Information 1002,1004 

dards such as ODBC, Another possible consideration is how FIG. 14 illustrates several components of the Information 

well the product accesses multiple files or databases, (source Services of the present invention. Information Services 

is market research) 50 manage electronic data assets and enable appUcations to 

What are the required features of the tool? access and manipulate data stored locally or remotely in 

Features to look for include but are not limited to: documents or databases. They minimize an application's 

WYSIWYG print preview dependence on the physical storage and location within the 

AbiUty to create views— prevents users fi-om getting network. Infonnation Services can be grouped into two 

overwhelmed with choices when selecting a table, acts categories: Database Services, and Document Services, 

as a security system by controlling which users have Database Services 1402 

access to certain data, and increases performance since Database Services are responsible for providing access to 

only the data users need gets downloaded to the report * 1°*=^ ^ remote database, maintaining integrity of the 

engine, thereby reducing network traffic. ^^^^a within the database and supporting the ability to store 

Data dictionary-^tore predefined views, formats, and ^^^^ ^^^.^^ ^ ^^y^"^ P^^^^^' °' ^ 

table and field name aliases. u i^^Sx "T" T ^7?"°' 

£L* Ji 4 1 vided by DBMS vendors and accessed via embedded or 

User triendiy query tool call-level SQL variants and supersets. Depending upon the 

Scnptmg or macro language underlying storage model, non-SQL access methods may be 

Supported data types and formats gs used instead. 

Formatting capabilities (page orientation, fonts, colors, Many of the Nctcentric applications are broadcast-type 

margins, condensed printing, etc) applications, designed to market products and/or publish 
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policies and procedures. Furthermore, there is now a growth SynchronizatioD Services perform the transactions 

of Netcentric applications that are transaction-type applica- required to make one or more information sources that are 

tions used to process a customers sales order, maintenance intended to mirror each other consistent. This function may 

request, etc. Typically these type of applications require especially valuable when implementing applications for 

integration with a database manager. Database Services 5 users of mobile devices because it allows a working copy of 

include: ^^^^ qj documents to be available locally without a constant 

Storage Services, Indexing Services, Security Services, network attachment. The emergence of applications that 

Access Services, and Replicatioa/Syochronization Ser- ^^^^^ collaborate and share knowledge has heig^it- 

vices. gjjgjj jjggj £qj. Synchronization Services in the execution 

Implementation Considerations * « 

JL J . . - 1. J 10 architecture. 

The core database services such as Security, Storage and rr. . ni*** joi.-*- j 
Access are provided by all major RDBMS products, . J^l terms Replication and Synchronization are used 
whereas the additional services of Synchrtinization and mterchangeably, depciidmg on the vendor, article book 
ReplicatioD are available only in specific products. cx^v}^. when Lotus Notes refers to Replication, it 
Product ConsideratioDS means both a combmation of Rephcation and Synchroniza- 
Oracle 7.3; Sybase SQL Server; Informix; IBM DB/2; tion Services described above. When Sybase refers to Rep- 
Microsoft SQL Server lication it only means copying data from one source to 
Oracle 7,3 — market leader in the Unix client/server another. 
RDBMS market, Oracle is available for a wide variety Implementation Consideration 

of hardware platforms including MPP machines. Replication/Synchronization Services are sometimes sup- 
Oracles market position and breadth of platform sup- 20 plied as part of commercial databases, document manage- 
port has made it the RDBMS of choice for variety of ment systems or groupware products such as Lotus Notes, 
financial, accounting, human resources, and manufac- Microsoft Exchange, Oracle, etc, 

turing application software packages. Informix — With Windows 95 and Windows NT 4.0, Microsoft has 

second in RDBMS market share after Oracle, Informix also introduced the concept of Replication/Synchronization 

is often selected for its ability to support both large 25 Services into the operating system. Through the briefcase 

centralized databases and distributed environments application users can automatically synchronize files and 

with a single RDBMS product. Sybase SQL Server— SQL data between their Windows PC and a Windows NT 

third in RDBMS market share, Sybase traditionally server. Underlying this application is the user-extensible 

focused upon medium-sized databases and distributed Win32 synchronization services API which can be used to 

environments; it has strong architecture support for 30 build custom synchronization tools, 

database replication and distributed transaction pro- Are changes in data usage anticipated? 

cessing across remote sites. Data can be dynamically changed to accommodate 

IBM DB2 — ^the leader in MVS mainframe database changes in how the data is used, 

management, IBM DB2 family of relational database Is it desirable to shield the user from the data access 

products are designed to offer open, industrial strength 35 process? 

database management for decision support, transaction A replicated database often consolidates data from het- 
prooessing and line of business applications. The DB2 erogeneous data sources, thus shielding the user from the 
family now spans not only IBM platforms like personal processes required to locate, access and query the data, 
computers, AS/400 systems, RISC System/6000 hard- What are the availability requirements of the system? 
ware and IBM mairiframe computers, but also non- 40 Replication provides high availability. If the master data- 
IBM machines such as Hewlett-Packard and Sun base is down, users can still access the local copy of the 
Microsystems, Microsoft SQL Server — the latest ver- database, 

sion of a high-performance client/server relational Is there a business need to reduce communication costs? 

database management system. Building on version 6.0, Depending on the configuration (real time vs. nightly 

SQL Server 6.5 introduces key new features such as 45 replication, etc.), there is a potential to reduce communica- 

transparent distributed transactions, simplified tions costs since the data access is local, 

administration, OLE-based programming interfaces, Is scalabihty an issue? 

improved support for industry standards and Internet With users, data, and queries spread across multiple 

integration. computers, scalability is less of a problem. 

Replication/Synchronization 1404 50 Can users benefit from the increased performance of local 

Replication Services support an environment in which data access? 
multiple copies of databases must be maintained. For Access to replicated data is fast since data is stored locally 
example, if ad hoc reporting queries or data warehousing and users do not have to remotely access the master data- 
applications can work with a replica of the transaction base. This is e^ecially true for image and document data 
database, these resource intensive applications will not inter- 55 which caimot be quickly accessed firom a central site, 
fere with mission critical transaction processing. Replication Making automatic copies of a database reduces locking 
can be either complete or partial. During complete replica- conflicts and gives multiple sets of users better performance 
tion all records are copied from one destination to another, than if they shared the same database, 
while during partial replication, only a subset of data is Product Considerations 

copied, as specified by the user or the program. Replication 60 What is the cuaent or proposed environment? 

can also be done either real-time or on-demand (i.e., initiated Platforms supported as well as source and target DBMS 

by a user, program or a scheduler). The following might be should be considered. 

possible if databases are replicated on alternate server(s): What are the technical requirements? 

better availability or recoverability of distributed applica- Products differ in features such as complete refresh vs. 

tions; better performance and reduced network cost, particu- 65 differential refresh (replication of changes), replication 

larly in environments where users are widely geographically granularity (row, table, database), method of capturing 

dispersed; etc. changes (snapshot, SQL statement intercept, trigger-based, 
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log-based), method of propagating copies (push, pull), database. Currently there are three contending archi- 

propagation timing controls (database event-driven, sched- tectures for providing gateway functions: 

uled based on interval, scheduled based on apphcaUon Distributed Relational Data Access (DRD A) is a standard 

event-driven, manually invoked), and conflict resolution promoted by IBM for distributed data access between 

mechanisms. Also important is what management utilities 5 heterogeneous databases. In this case the conversion of 

are available with the product the format and protocols occurs only once. It supports 

Arc available resources and issue? SQL89 and a subset of SQL92 standard and is built on 

Products vary in the amount of resources required to top on APPC/APPN and TCP/IP transport stacks, 

instdl and operate the system. jgj.^ EDA/SQL and the Sybase/MDI Open Server use 

mat arc the busmess requirements? lo ^ relational and non-relaUonal database 

Three key considerations arc: systems. Hiey use APIySQL or T-SQL respectively as 

Who owns and uses the data? Replication products sup- the standard interface language. A large number of 

port one or more of the three ownership models: communication protocols are supported including 

Primary site ownership— data is owned by one site; NetBIOS, SNA, DecNET, TCP/IP. The main engine 

Dynamic site ownership — data owned by one site, 15 translates the client requests into specific server calls. It 

however site location can change; and Shared site handles security, authentication, statistics gathering and 

ownership^ata ownership is shared by multiple sites. some system management tasks. 

Which of the four basic types of replication style is Implementation Considerations 

appropriate? The four styles are: Data dissemination — Gateways may create bottlenecks, because all the clients 
portions of centrally maintained data are replicated to ^ go through a single gateway, 

the appropriate remote sites; Data consolidation— data Sec\irity 1410 

is replicated from local sites to a central site where all Security Services enforce access control to ensure that 

local site data is consolidated; Replication of logical records are only visible or editable by authorized people for 

partitions— replication of partitioned data; and Update approved purposes. Most database management systems 

anywhere— multiple remote sites can possible update provide access control at the database, table, or row level as 

same data at same time. well as concurrency control. 

What is the acceptable latency period (amount of time the Implementation Considerations 

primary and target data can be out of synch)? There are Will the application be used in a distributed environment? 
three basic replication styles depending on the amount ^ Jn a distributed environment, the need exists to provide 

of latency that is acceptable: Synchronous^eal-time access to the corporate data and resources in a secure and 

access for all sites (no latency); Asynchronous near controlled manner. This access depends on the role of the 

real-time — short period of latency for target sites; user, the user group, etc. within that environment. Since 

Asynchronous batch/periodic — predetermined period security is an architecture component where functionality 

of latency for all sites. and robxistness vary across engagements, the architectures 

Do I akeady have a component that satisfies this criteria? usually provide a base set of security functions. These 

Many DBMS vendors ship replication products as either functions target securing the systems corporate data and 

part of the base package or as an additional feature. resources, as opposed to securing an applications detailed 

Possible Product Options functions. 

Sybase Replication Server; Oracle Symmetric Replication; ^ Thesecurity component prevents unauthorized users from 

CA-Ingres Replicator; InfoPump; DataPropagator Rela- accessing corporate data/resources by providing the users 

tional; Informix Replicator vnth access codes-password & ID— that allows the user to 

Access 1408 login to the system or execute any (or a particular) appli- 

Access Services enable an application to retrieve data cation, 

from a database as well as manipulate (insert, update, delete) Security components can restrict access to functions 

data m a database. SQL is the prunary approach for access- ^Hun ^ application based on a users security level. The 

ing records in today's database management systems, highest level security is whether the user has access to run 

aientHserver systems often require data access firom the application. The next level checks if the user has access 

multiple databases offered by different vendors. This is often to functions within the application, such as service calls or 

due to mtegraUon of new systems with existing legacy windows. At an even lower level, the security component 

systems. Tlie key architectural concern is m building the ^o^ld check security on more granular functions, such as 

application where the multi-vendor problem is transparent to \vridgcts on a window 

the cUent. This provides future portabUity, flexibility and Security usually resides on both the cHent and server 

also makes It easier for application developers to write to a pj^^form in a distributed environment. True security should 

smgle database access interface. Achievmg database access ^^^y^ placed on the server platform, to protect the 

transparency requires the foUowmg: ^^^^^ ^^^^^ ^^^^ ^^^-^^ ^ ^^^^^ application. 

Standards Based SQL API — this approaches uses a single, is there a direct/indirect relationship between the user 

standards based set of APIs to access any database, and role/group and the data/services? 

includes the following technologies: Open Database There are situations where it is required for the system to 
Connectivity (ODBC), Java Database Connectivity ^ maintain the relationship of the users role and the users 

(JDBC), and Object Linking and Embedding (OLE access to specific system servicesAesources. For example, a 

^^)* database administrator will have read-write-delete access to 

SQL Gateways provide a mechanism for clients to trans- the database, whereas a sales manager will have only read 

parently access data in a variety of databases (e.g., access to it for viewing the data in various forms. The 
Oracle, Sybase, DB2), by translating SQL calls written 65 security component should provide the functionality for 

using the format and protocols of the gateway server or validating the users resource access privileges based on the 

primary server to the format and protocols of the target role of the user. 



06/17/2004, EAST Version: 1.4.1 



us 6,6: 

53 

ladexing 1412 

Indexing Services provide a mechanism for speeding up 
data retrieval. In relational databases one or more fields can 
be used to construct the index. So when a user searches for 
a specific record, rather than scanning the whole table 
sequentially the index is used to find the location of that 
record faster. 
Storage 1414 

Storage Services manage data physical storage. These 
services provide a mechanism for saving information so that 
data wiU live beyond program execution. Data is often 
stored in relational format (an RDBMS) but may also be 
stored in an object-oriented format (OODBMS) or other 
formats such as IMS, VSAM, etc. 
Document Services 1416 

Document Services provide similar structure and control 
for documents that database management systems apply to 
record oriented data. A docimient is defined as a collection 
of objects potentially of different types (e.g., structured data, 
unstructured data, images, multi-media) a business user 
deals with. An individual document might be a table created 
using a spreadsheet package such as Microsoft Excel, a 
report created using a word processing package such as 
Lotus AmiPro, a Web page created using an HTML author- 
ing tool, unstructured text or a combination of these object 
types. Regardless of the software used to create and maintain 
the component parts, all parts together constitute the 
document, which is managed as a single entity. 

Netcentric applications that are executed from a browser 
are particularly well suited for serving up document style 
information. If the Web application consists of more than 
j\ist a few HTML documents, integration with a document 
management system should be considered. Document Ser- 
vices include: Storage Services, Indexing Services, Security 
Services, Access Services, Replication/Synchronization 
Services, and Versioning Services. 
Possible Product Options 
Documentum Server; Saros; PC Docs 

Documentum — Documentxun Enterprise Document Man- 
agement System (EDMS) automates and accelerates 
the creation, modification, and reuse of business- 
critical documents, Web pages, and other unstructured 
data and all of the collaborative efforts involved. 

Saros — Saros Discovery Suite is the next generation 
client/server solution that integrates Saros Document 
Manager, FileNet Ensemble and Watermark 

Gienl to provide powerful, tightly-integrated electronic 
document management, workflow, and document- 
imaging capabilities. 
Versioning 1418 

Versioning Services maintain a historical record of the 
changes to a document over time. By maintaining this 
record, these services allow for the re-creation of a docu- 
ment as it looked at any given point in time during it's 
evolution. Additional key versioning features record who 
made changes when and why they were made. 
Replication/Synchronization 1404 

Replication Services support an environment in which 
multiple copies of documents must be maintained. A key 
objective is that documents should be shareable and search- 
able across the entire organization. Therefore, the architec- 
ture needs to provide logically a single repository, even 
though the documents are physically stored in different 
locations. The following might be possible if documents are 
replicated on alternative server(s): better availability or 
recoverability of a distributed application; better perfor- 
mance; reduced network cost; etc. 
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Synchronization Services perform the transactions 
required to make one or more information sources that arc 
intended to mirror each other consistent. They support the 
needs of intermittently connected users or sites. Just like for 

5 databases, these services are especially valuable for users of 
mobile devices that need be able to work locally without a 
constant network coimection and then be able to synchronize 
with the central server at a given point in time. 
Implementation Considerations 

10 Products such as Lotus Notes and Microsoft Exchange 
allow remote users to replicate documents between a client 
machine and a central server, so that the users can woik 
disconnected firom the network. When reattached to the 
network, users perform an update that automatically 

15 exchanges information on new, modified and deleted docu- 
ments. 

Note: Both Lotus Notes and MS Exchange provide a 
limited subset of the Document Services described in this 
section. This should be carefully evaluated when consider- 
20 ing these products to provide document management ser- 
vices. 

Access 1408 

Access Services support document creation, maintenance 
and retrieval. These services allow users to capture knowl- 

25 edge or content through the creation of unstructured 
information, i.e. documents. Access Services allow users to 
effectively retrieve documents that were created by them and 
docxmients that were created by others. Documents can be 
comprised of many different data types, including text, 

30 charts, graphics, or even audio and video. 
Security 1410 

Documents should be accessed exclusively through the 
document management backbone. If a document is checked- 
in, check-out, routed, viewed, annotated, archived, or 
35 printed it should be done only by users with the correct 
security privileges. Those access privileges should be able to 
be controlled by user, role, and group. Analogous to record 
locking to prevent two users from editing the same data, 
document management access control services include 
40 check-in/check-out services to limit concurrent editing. 
Indexing 1412 

Locating documents and content within documents is a 
more complex problem and involves several alternative 
methods. The Windows file manager is a simplistic imple- 
45 mentation of a hierarchical organization of files and collec- 
tion of files. If the user model of where documents should be 
stored and foimd can be represented in this way, the use of 
structure and naming standards can be sufBcient. However, 
a hierarchical document filing organization is not suitable 
50 for many types of document queries (e .g., retrieving all sales 
order documents for over $1,000). 

Therefore, most docxmicnt management products provide 
index services that support the following methods for 
searching document repositories: 
55 Attribute Search — scans short lists (attributes) of impor- 
tant words that are associated with a document and 
returns documents that match the search criteria. For 
example, a user may query for documents written by a 
specific author or created on a particular date. Attribute 
60 search brings the capabilities of the SQL-oriented data- 
base approach to finding documents by storing in a 
database the values of specially identified fields within 
a document and a reference to the actual document 
itself. In order to support Attribute Search an index 
65 maintains documents' attributes, which it uses to 
manage, find and catalog documents. This is the least 
complicated approach of the searching methods. 
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FuU-text Search — searches repository contents for exact such as Oracle or Sybase. Attributes are stored within 

words or phrases and returns documents that match the traditional database data types (e.g., integer, character, 

search criteria. In order to facilitate Full-text Search, etc.); contents are stored in the database's BLOB 

fiill-text indexes are constructed by scanning docu- (Binary Large Objects) data type, 

ments once and recording in an index file which words 5 Industry standard database and file system — Documents' 

occur in which documents. Leading docimicnt manage- attributes are stored in an industry standard database, 

mcnt systems have fiill-text services built-in, which can and documents' contents are usually stored in the 

be integrated direcUy into applications. file-system of the host operating system. Most docu- 

Cbntext Search-searches repository contents for exact management products use this document storage 

words or phrases. Also, searches for related words or lO method because today this appr^^ 

. , . ' J J . • flexibility m terms of data distnbution and also allows 

phrases by using synonyms and word taxonomies. For ^^^j. s^^alability 

example, if the user searches for auto, the search engine Communication 1006,1008 

should look for car, automobile, motor vehicle, etc. ^ illustrated in FIG. 15, Network services provided by 

Boolean Search — searches repository contents for words the Communications Services layer are grouped into four 

or phases that are joined together using boolean opera- major categories of functionality: Virtual Resource, 

tors (e.g., AND, OR, NOT). Same type of indexes are Directory, Messaging, and Security services 1502,1504, 

used for Boolean Search as for Full-Text Search. 1506,1508. 

Ihe following products are used to index and search Web Virtual Resource services proxy or mimic the capabilities 

and non-Web documents: of specialized, network connected resources. This allows a 

Verity Topio^elivers accurate indexing, searching and ^ generic network node to emulate a specialized physical 

filtering of a wide variety of information sources and ^^^^3^^- ^^y^ "^^^rk users can interface with a 

formats. Verity Topic is integrated directly into several ^^!?^ty of specialized resources. 

document management products, allowing systems to ^ Directoiy services play a key role m network archite^^^^^ 

full-text index its unstructured information. Verity ^'^^^^ t^eir abihty to umfy and manage distributed 

• 1 «• i^otiuwuivu lULui^iiioLiuii. Ywiij^ environments. Managmg information about network 

Topic also ofei^ a vanety of products to help M-text ^ ^^^^^^^^^ -^^^^^^^ ^ ^J^^^ ^^^^^^^ ^^^^^ ^^^^ 

mdex Web sites. simple name/address resolution to the logical integration of 

Rilcmm— provides a variety of robust, multi-platform heterogeneous systems to create a common view of services, 

indexing and retrieval products that deliver full- security, etc, 

function text retrieval capabilities. Fulcrums products Messaging services transfer formatted information from 

are typically integrated with custom databases, Web one process to another. These services shield applications 

sites and document management systems, fi:om the complexity of the network transport services. 

The following products are mainly used for Web docu- Call centers and customer service centers are integral 

ments: parts of many business operations. Call centers have . 

Microsoft Index Server 1.1— allows for search of Web enhanced business processes by managing telephone contact 

documents, including Microsoft Word and Microsoft potential customers, with the objective of improving 

Excel It works with Windows NT ^® Quality of Service (QoS). Several customer and business 

Server 4.0 and Internet Information Server 2.0 or higher ^^^^ "Tf '^''l^^^f^ ^ ''"^'^ '^"""^ f^'' 

to provide access to documents stored on an intraneTor ^,^fl!f "^^^^^^^^^^ ^^""""^ "° 

i/^ ^TJc^ .i^ii^^ u customer mteraction. 

Internet Site. Index Server supports full-text searches ^ Communications Security services control access to 

and retaeves a^l types of informaUon from the Web network-attached resources. Combining network Security 

browser includmg H™l, text, and all Microsoft ^^vices with security services in other parts of the system 

Office documents, m their ongmal fomiat architecture (e.g., appUcation and database layers) results in 

Netscape Catalog Server 1.0 — provides an automated robust security, 

search and discovery server for creating, managing, and 45 JmplemenUtion Considerations 

keeping current an ooUne catalog of documents resid- is data translation required? 

ing on corporate intranets and the Internet. Catalog Communications middleware can translate data into a 

Server offers query by full text, category, or attributes format that is compatible with the receiving process. This 

such as title, author, date, etc. It also supports multiple may be required in a heterogeneous environment. An 

file formats, including HTML, Word, Excel, 50 example is data translation from ASCII-to-EBCDIC. It is 

PowerPomt, and PDF important to note that data translation may not be provided 

Storage 1414 \yy jji niiddleware products. 

Storage Services manage the document physical storage. Are additional communicaUons services required? 

Most document management products store documents as Communications middleware can provide additional 

objects that include two basic data types: attributes and 55 communications services that may be required by the appU- 

content. Document attributes are key fields used to identify cations. Additional services include dynamic message 

the document, such as author name, created date, etc. routing, guaranteed deUvery, broadcasting, queuing, and 

Document content refers to the actual unstructured infoima- priority delivery. These common services are usually pro- 

tion stored within the document. Generally, the documents vided in the communications middleware rather than 

are stored in a repository using one of the foUowing meth- go addressing them in each application separately. Different 

communications middleware products provide different ser- 

Proprietary database — documents (attributes and vices. Additionally, many middleware packages, such as 

contents) are stored in a proprietary database (one that Tuxedo, provide OLTP functionahty, 

the vendor has specifically developed for use with their Is a packaged middleware solution desired? 

product). 65 Depending on the functionality required, communications 

Industry standard database — documents (attributes and middleware can be very complex to custom develop. In 

contents) are stored in an industry standard database addition, products have evolved to a point where proven 
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solutions exist. Based on this, it can be desirable to buy 
communications middleware rather than to build it. Consid- 
erations of time, budget, skills, and maintenance should be 
taken into account when selecting between a packaged 
middleware product and custom developed middleware. In 5 
some instances, custom developed middleware may still be 
preferred. 

What is the clients middleware direction? 

There is a definite functionality overlap between commu- 
nications middleware and several other middleware compo- lo 
nents such as transaction services and information access. In 
addition, communications middleware may be provided by 
various CASE tools. An example of this is the Distribution 
Services component of FCP. Because of this overlap, it is 
important to understand the clients overall direction toward 15 
middleware and the specific middleware functionality 
required by the overall solution. 

Is a simplified developers interface important? 

The simplified interface associated with communications 
middleware can help to reduce the complexity of developing 20 
Netcentric applications. The simphfied interface helps 
reduce the development complexity by insulating the busi- 
ness apphcations from the netwoiic protocols. Because of 
this, application developers do not need to understand the 
intricacies and somewhat cryptic APIs associated with net- 25 
work transport protocols. 

Is location transparency required? 

Communication middleware allows the chent application 
to access any service on any physical server in the network 
without needing to know where it is physically located. This 30 
capability may be required in an environment with many 
physical servers or in an environment that is very dynamic. 
It is important to note that location transparency may not be 
provided by all middleware products. 

Does the apphcation need to run on multiple platforms? 35 

Communications middleware is designed to allow appli- 
cations to access various transport protocols from various 
vendors. From a network interface perspective, it should be 
easier to port an application from one computing platform to 
another if the application is using communications middle- 40 
ware. Of course, other porting issues will need to be con- 
sidered. 

Virtual Resources 1502 

Virtual Resource services proxy or mimic the capabiUties 
of specialized, network-connected resources. This allows a 45 
generic network node to emulate a specialized physical 
device. In this way, network users can interface with a 
variety of specialized resources. An examples of a Mrtual 
Resource service is the capabiUty to print to a network 
printer as if it were directly attached to a workstation. 50 
Fax 1510 

Fax Services provide for the management of both 
in-bound and out-bound fax transmissions. If fax is used as 
a medium for communicating with customers or remote 
employees, in-bound fax services may be required for cen- 55 
trally receiving and electronically routing faxes to the 
intended recipient. Out-bound fax services can be as simple 
as supporting the sharing on the network of a single fax 
machine or group of machines for sending faxes. 

Fax services can provide centrally managed faxing 60 
capabilities, thus eliminating the need for fax modems on 
every workstation. A fax server generally provides Fax 
services to clients, such as receiving, queuing, and distrib- 
uting incoming faxes and queuing and sending outgoing 
faxes. Chents can view faxes and generate faxes to be sent. 65 

Applications may compose and transfer faxes as part of 
notifying users or deUvering information. For example, an 
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application may use Fax services to add customer-specific 
information to a delivery receipt form and fax the form to a 
customer. 

Implementation Considerations 

More sophisticated out-bound fax architecture services 
are required for supporting fax-back applications. Fax-back 
applications, when coupled with Computer Telephone Inte- 
gration (CTI) are popular for automating customer requests 
for product or service information to be faxed to them. 
Possible Product Options 

Cheyenne Softwares Faxscrvc; Lotus Fax Server for Lotus 

Notes; Sirens Siren Fax 

The following are examples of fax servers: 

The Lotus® Fax Server (LFS) — ^provides fax services to 
users working on a network running NotesMail®. In 
addition to combining outgoing and incoming fax capa- 
bilities in a single product, the LFS provides additional 
features, such as automatic routing, and print-to-fax 
driver software that extends fax capabilities to any 
Windows-based Notes client. The LFS supports a wide 
variety of fax modems, fax cards and fax file formats 
through the incorporation of device technologies from 
Optus Software, Inc. 

Cheyenne Software's Faxserve 

The following is an example of a product that allows 
applications to generate faxes: 

Siren's Siren Fax 
File Sharing 15U 

FIG. 16 illustrates File Sharing services 1512. File Shar- 
ing services allow users to view, manage, read, and write 
files that may be located on a variety of platforms in a variety 
of locations. File Sharing services enable a unified view of 
independent file systems. This is represented in FIG. 16, 
which shows how a client can perceive remote files as being 
local. 

File Sharing services can provide the following capabili- 
ties: 

Transparent access — access to remote files as if they were 
local 

Multi-user access — distribution and synchronization of 
files among multiple users, including file locking lo 
manage access requests by multiple users 

File access control — use of Security services (user 
authentication and authorization) to manage file system 
security 

Multi-platform access — access to files located on various 

platforms (e.g., UNIX, NT, etc) 
Integrated file directory — a logical directory structure that 

combines all accessible file directories, regardless of 

the physical directory structure 
Fault tolerance — ^use of primary and replica file servers to 

ensure high availability of file system 
ScalabiUty — abiUty to integrate networics and distributed 

file systems of various sizes 
Possible Product Options 

Novell's NetWare/IntranetWare; Microsoft's Windows NT 
Server; Sun Microsystems NFS and WebNFS; Novell's 
IntranetWare NFS Services; IBM/Transarcs Distribute 
File System (DFS); Transarc's AFS 
The following are examples of File Sharing products: 
Novell's NetWare/IntraoetWare— Novell's NetWare net- 
work operating system includes distributed file 
services, supported by the NetWare Core Protocol 
(NCP). NetWare Directory Services (NDS) manages 
naming and security for files on distributed platforms. 
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Microsoft's Windows NT Server 

Server Message Block (SMB) — native file-sharing pro- 
tocol in Windows 95, Windows NT, and OS/2. 

Common Internet File System (CIFS) — an enhancement 
to SMB for distributed file systems in a TCP/IP envi- 
ronment. 

Distributed File System (Dfis)— a utility for Windows NT 
Server that provides file services in a Microsoft envi- 
ronment. 

Network File System (NFS) — NFS is a native UNIX file 
access protocol and is dso available as an operating 
system add-on product that provides distributed file 
services. Sun Microsystems introduced NFS in 1985. 
NFS has becD widely adopted and has been ported to a 
variety of platforms. 

The following are examples of products that provide NFS 
services. 

Sun Microsystems' NFS and WebNFS Novell's Intranet- 
Ware NFS Services 

AFS — distributed file system for distributed UNIX 
networks; derived from Carnegie-Mellon University's 
Andrew File System. Similar to NFS, but differs in terms of 
the name space, system performance, security, etc. AFS is 
distributed by Transarc. 

IBM/IVansarc's Distribute File System (DFS)--a scale- 
able distributed file system that offers replication, security, 
etc. 

Paging 714 

Wireless short messaging (i.e., paging) can be imple- 
mented through wireless systems such as paging networks, 
GSM voice/data networks, PCS voice/data networks, and 
dedicated wireless data networks. Paging virtual resource 
services provide the message formatting and display func- 
tionality that allows network nodes to interface with wireless 
paging systems. This service emulates the capabilities of 
one-way and two-way pagers. Paging systems allow pages 
to be generated in various ways: 

E-mail messages to a specified mailbox 
DTMF (touch tone) signaling to a voice response system 
Encoded digital messages transferred into a paging pro- 
vider gateway 

Messages transferred to a locally attached two-way wire- 
less pager 
Possible Product Options 
TelAlert; E-mail Systems 

e-mail systems — some e-mail systems and fax servers can 
be configured to generate pages to notify users when a 
defined event occurs such as e-mail/fax arriving. 
Telamon's TelAlert — TelAlert provides notification capa- 
bilities for UNIX systems. For example, it can page 
support personnel in the event of system problems. 
Phone 1516 

Phone virtual resource services extend telephony capa- 
bilities to computer platforms. For example, an application 
on a desktop computer can place and receive telephone calls 
for the user. Phone virtual resource services may be used in 
customer care centers, help desks, or any other environment 
in which it is \iseful for a computer to replace a telephone 
handset 

Phone services enable clients, servers, and specialized 
telephony nodes (PBXs, ACDs, etc.) to control the tele- 
phony enviromnent through the following telephony con- 
trols: 
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Call control 

Controls telephone features 
Controls recorded messages 

Manipulates real time call activities (e.g., make call, 
answer, transfer, hold, conference, mute transfer, 
release, route call, call treatments and digits 
collected) 
Telephone status control 

Controls telephone status functions 
Logs Tisers in and out of the system 
Sets ready, not ready, and make busy statuses for users 
The following are examples of uses of Phone virtual 
resources: 

PC Telephony — ^PC telephony products allow desktop 
computers to act as conduits for voice telephone calls. 

Internet Telephony — Internet telephony products enable 
voice telephone calls (and faxing, voice mail retrieval, 
etc) through the Internet, For example, an Internet 
telephony product can accept voice input into a 
workstation, translate it into an IP data stream, and 
route it through the Internet to a destination 
workstation, where the data is translated back into 
audio. 

Desktop Voice Mail — Various products enable users to 
manage voice mail messages using a desktop computer. 
Possible Product Options 

Lucent PassageWay; COM2001s TransCOM; NetSpeaks 
WebPhone; VocalTecs Internet Phone; IDTs Net2Phone; 
Octet Communications Unified Messenger 
The following arc examples of vendors that provide PC 

telephony products: 
Lucent PassageWay — suite of products that connect PCs 
to PBXs. 

COM200rs TransCOM— voice, data and call- 
management system (dialing, voice mail, faxing, voice 
recognition, caller ID, etc) for personal computers. 

Hie following are examples of Internet telephony prod- 
ucts: 

NetSpeak's WebPhone 
VocalTec's Intemet Phone 
IDTs Net2Phone 

The following is an example of a desktop voice mail 
product: 

Octel Communication's Unified Messenger 
Terminal 1518 

Terminal services allow a client to connect to a non-local 
host via a network and to emulate the profile (e.g., the 
keyboard and screen characteristics) required by the host 
application. For example, when a workstation application 
logs on to a mainframe, the workstation functions as a dumb 
terminal. Terminal Services receive user input and send data 
streams back to the host processor. If connecting from a PC 
to another PC, the workstation might act as a remote control 
terminal (e.g., PCAnywhere). 
The following are examples of Terminal services: 
Telnet — a simple and widely used terminal emulation 
protocol that is part of the TCP/IP communications 
protocol Telnet operates establishing a TCP connection 
with the remotely located login server, minicomputer or 
mainfirame. Hie client's keyboard strokes are sent to 
the remote machine while the remote machine sends 
back the characters displayed on the local terminal 
screen. 

3270 emulation— emulation of the 3270 protocol that is 
used by IBM mainframe terminals. 



06/17/2004, EAST Version: 1.4.1 



us 6,636; 

61 

tii3270 — a Telnet program that includes the 3270 protocol 
for logging onto IBM mainframes; part of the TCP/IP 
protocol suite. 

X Window System — allows users to simuiltaneously 
access applications on one or more UNIX servers and 5 
display results in multiple windows on a local display. 
Recent enhancements to XWS include integration with 
the Web and optimization of network traflBc (caching, 
compression, etc.). 

Remote control — While terminal emulation is typically jq 
used in host-based environments, remote control is a 
sophisticated type of client/server Terminal service. 
Remote control allows a client computer to control the 
processing on a remote desktop computer. The GUI on 
the client computer looks as if it is the GUI on the 25 
remote desktop. This makes it appear as if the remote 
applications are running on the client. 

rlogin — a remote terminal service implemented under 
BSD UNIX. The concept behind rlogin is that it sup- 
ports "trusted" hosts. This is accompHshed by having a 20 
set of machines that share common file access rights 
and logins. The user controls access by authorizing 
remote login based on a remote host and remote user 
name. 

Possible Product Options 25 
Hummingbird's Exceed; Network Computing Devices' 

PC-Xware; Citrix WinFrame; Carbon Copy; pcANY- 

WHERE; Stac's Reachout; Traveling Software's LapLink 

The following are examples of X Window System prod- 
ucts: 30 

Hummingbird's Exceed 

Network Computing Devices' PC-Xware 

The following are examples of remote control products: 

atrix's WinFrame 

Microcom's Carbon Copy 

Symantec's pcANYWHERE 

Stacks Reachout 

Traveling Software's LapLink 
Printing 1520 ^ 

Print services connect network workstations to shared 
printers. The administration of Print Services is usually 
handled by a print server. Depending on the size of the 
network and the amount of resources the server must 
manage, the print server may run on a dedicated machine or 
on a machine that performs other server functions. Aprimary 
function of print servers is to queue print jobs sent to 
network printers. The queued jobs are stored in a print buffer 
on the print server and are sent to the appropriate network 
printer as it becomes available. Print services can also 
provide the client with information including print job status 
and can manage in-progress print jobs. 
Possible Product Options 

Novell's Netware Distributed Print Services (NDPS); Nov- 
ell's Netware UNIX Print Services; Microsoft; Windows 
NT Server; Line Printer Daemon (LPD) 
The following are examples of print server products: 
Novell's Netware Distributed Print Services (NDPS) — 
provides central management of print services for Net- 
Ware networks. 
Novell's Netware UNIX Print Services — a supplement to 
Novell's NetWare 4,1 server which allows NetWare 
and UNIX cUents to share UNIX or Netware printers. 
Microsoft Windows NT Server — provides central man- 
agement of print services for NT networks. 65 
Line Printer Daemon (LPD) — UNIX print management 
facilities, which include cLent and server utilities for 
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spooling print jobs. Related programs include 1 pr 
(sends print job to spool) and 1 p (sends request to 
printer), 
AudioMdeo 1522 

Audio/Video services allow nodes to interact with multi- 
media data streams. These services may be implemented as 
audio -only, video-only, or combined audioMdeo: 
Audio services — Audio services allow components to 
interface with audio streams such as the delivery of 
music or radio content over data networks. 
Video services — Video services allow components to 
interface with video streams such as video surveillance. 
Video services can add simple video monitor capabili- 
ties to a computer, or they can transform the computer 
into a sophisticated video platform with the ability to 
generate and manipulate video. 
Combined AudioA^ideo services — ^Video and audio con- 
tent is often dcUvered simultaneously. This may be 
accomplished by transferring separate audio and video 
streams or by transferring a single interleaved stream. 
Examples include video conferencing and television 
(traditional or interactive). 
AudioMdeo services can include the following function- 
ality: 

Streams content (audio, video, or both) to end users 
Manages buffering of data stream to ensure uninterrupted 

viewing/listening 
Performs compression and decompression of data 
Manages communications protocols to ensure smooth 

delivery of content 
Manages library of stored content and/or manages gen- 
eration of live content 
AudioA^deo services draw upon lower-level services 
such as streaming and IP Multicast in order to efficiently 
deliver content across the network. 
Possible Product Options 

Progressive Networks Real\^deo; Microsoft's NctShow; 
Vxtrcmes Web Theater; Intels ProShare; Creative Labs 
Video WebPhone 

The following products are examples of video servers: 
Progressive Networks' RealVideo 
Microsoft's NetShow 
Vxtrcme's Web Theater 

The following products are examples of video conferenc- 
ing systems: 
Intel's ProShare 

Creative Labs' Video WebPhone 
Directory Services 1504 

A full-featured Directory Service organizes, categorizes 
and names networked resources in order to provide a com- 
prehensive picture of clients, servers, users, applications and 
other resources. The service typically includes a database of 
objects, representing all nodes and resources on a network. 
The database manages relationships between users and 
networks, network devices, network applications, and infor- 
mation on the network. The Directory service can organize 
network nodes to reflect the topology and organization of the 
enterprise and its policies. The Directory service makes 
resources location and platform independent, since it allows 
users to locate resources via the directory and regardless of 
their physical location. The Directory service also maps 
between bgical resource names (e.g., "Marketing_Printer^*) 
and physical resource address (e.g., 10.27.15.56). (See 
Name service, below). 

Directory service products utilize Security services to 
track access rights for access to network resources and 
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information. The Directory service -is an efficient way to 
manage resource security, since the directory offers a logical 
representation of all resources in the enterprise. In addition, 
the Directory service caQ act as a single point of entry into 
the network, meaning users can receive access to allowed 
resources by authenticating themselves a single time to the 
Directory service, (For more information on authentication 
and authorization, refer to the Comm. Security service.) 

In summary, the Directory service performs the following 
functions: 

Stores information about network resources and users and 
tracks relationships 

Organizes resource access information in order to aid 
resources in locating and accessing other resources 
throughout the network 

Provides location transparency, since resources are 
accessed through a directory rather than based on their 
physical location 

Converts between logical resource names and physical 
resource addresses 

Interacts with Security services such as authentication and 
authorization track identities and permissions 

Provides single network logon to file and print resources; 
can provide single network logon for network applica- 
tions that are integrated with the Directory service 

Distributes directory information throughout the enter- 
prise (for reliability and location-independent access) 

Synchronizes multiple directory databases 

Enables access to heterogeneous systems (integration of 
various network operating systems, platforms, etc.) 

Directory Standards — There are a variety of standards for 
directories. Vendor-specific directory products build upon 
(and extend) standards to provide a robust, full-featured 
enterprise directory. 

TTie following are examples of standards related to Direc- 
tory services; 

X.500 an ITU-T standard for a hierarchical directory 
containing user and resource information; includes 
Directory Access Protocol (DAP), which can be used to 
access directory information. 

Lightweight Directory Access Protocol (LDAP) a de facto 
standard for accessing X.SOO-compatible directory 
information in an Internet/intranet environment. 
Implementation Considerations 

One of the most popular network directory services is 
Novell Directory Services (NDS) used with Netware 4.x. 
This system allows users to access services and resources 
with a single login, regardless of where the user location is 
or where the resource location is. Another example of a 
directory service is the ISO X.500 standard. Hiis method is 
not widely used due to its high overheads. In addition to 
these two protocols, Windows NT uses a similar system 
caUed Primary Domain Control. This system allows for the 
same type of directory mapping as NDS and X.500. 

Another protocol that has emerged is the Lightweight 
Directory Access Protocol (LDAP), which is a slimmed- 
down version of the X.500 directory client and is seen as a 
possible replacement for X.500. LDAP is a standard proto- 
col for accessing and updating directory information in a 
client/server environment; it has evolved into an emerging 
standard for directory replication for the Internet, and is 
backed by vendors such as Netscape, Novell, Microsoft, 
IBM and AT&T that can provide low-level compatibility 
among directory systems. 

Another helpful feature to look out for is support for 
dynamic IP addressing via DHCP. This lets the router handle 
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the process of sharing a small number of IP addresses among 
the members of the workgroup. Support for dynamic IP 
addressing is now part of Windows 95 and Macintosh 
System 7.6, among other operating systems. 
Possible Product Options 

NovcUs Netware Directory Service; Nctscapcs Directory 
Server; Microsofts Active Directory; Banyan Systems 
StreetTalk 

The following are examples of products that provide 
fiill-fcatured Directory services. 
Novell's Netware Directory Service 
Netscape's Directory Server 

Microsoft's Active Directory Banyan Systems* StreetTalk 
The following is an example of a meta-directory product: 
Zoomit VIA — integrates network operating system 
directories, application databases, and human resource 
databases (includes Lotus cc:Mail, Lotus Notes, Novell 
NDS, Microsoft NT Domain Controller and Active 
Directory, Microsoft Exchange, Banyan VINES, 
Netscape Directory Server), thus allowing unified 
access and maintenance. 
The following are examples of Name services: 
Domain Name Service — The most common and widely 
used Name Service on the Internet is Domain Name 
Service (DNS) which resolves a pronounceable name 
into an IP address and vice versa. For instance, DNS 
could resolve the domain name of www.ac.com to be 
204.167.146.195. DNS functionality is distributed 
across many computers within the network. 
Microsoft's Windows Intemet Name Service (WINS) — 
WINS is Microsoft's proprietary method for mapping 
IP addresses to NetBIOS device names. WINS works 
with Windows 3.x, Windows 95, and Windows NT 
clients. 

The following are examples of products that provide 
Domain services: 

Network Information Service (NIS) — Developed and 
licensed by Sun Microsystems for use in UNIX 
environments, NIS tracks user names, passwords, user 
IDs, group IDs, and host names (along with other 
system files) through a centralized NIS database. 

Microsoft's Windows NT Server Domain Controller 
Domain Services 1524 

A network domain is a set of network nodes under 
common control (i.e., common security and logins, unified 
addressing, coordinated management, etc.). Domain ser- 
vices manage these types of activities for the network nodes 
in a domain. Domain services may be limited in their ability 
to support heterogeneous systems and in the ability to scale 
to support the enterprise. 
Name Service 1526 

The Name service creates a logical "pronounceable" 
name in place of a binary machine number. These services 
could be used by other communications services such as File 
Transfer, Message Services, and Terminal Services. A Name 
service can be implemented on its own, or as part of a 
full-featured Directory service. 
Core Messaging 1528 

Broadly defined. Messaging services enable information 
or commands to be sent between two or more recipients. 
Recipients may be computers, people, or processes within a 
computer. Messaging Services are based on specific proto- 
cols. A protocol is a set of rides describing, in technical 
terms, how something should be done. Protocols facilitate 
transport of the message stream. For example, there is a 
protocol describing exactly what format should be used for 
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sending specific types of mail messages. Most protocols 
typically sit "on top*' of the following lower level protocol: 
TCP/IP — ^Transmission Control Protocol/Internet Proto- 
col (TCP/IP) is the principle method for transmitting 
data over the Internet today. This protocol is respon- 
sible for ensuring that a series of data packets sent over 
a network arrive at the destination and are properly 
sequenced. 

Messaging services transfer formatted information from 
one process to another. By drawing upon Messaging 
services, apphcations can shield themselves from the com- 
plexity of the low-level Transport services. The Core Mes- 
saging services category includes styles of messaging that 
support basic inter-process communication (IPC). There are 
a variety of architecture options used to support IPC. They 
can be divided into Store and Forward, Synchronous and 
Asynchronous Message Services, 

Store and Forward Message Services — provide deferred 
message service processing. A Store and Forward Message 
Service may use an E-Mail infrastructure upon which to 
build applications. Common uses would be for forms rout- 
ing and E-mail. 

Synchronous Message Services — allow an appUcation to 
send a message to another appUcation and wait for a reply 
before continuing. Synchronous messaging is typically used 
for update and general business transactions. It requires 
time-out processing to allow the application to re-acquire 
control in the event of failure. 

Asynchronous Message Services allow an application to 
send a message to another application and continue process- 
ing before a reply is received. Asynchronous messaging is 
typically used for larger retrieval type processing, such as 
retrieval of larger lists of data than can be contained in one 
message. 

Additionally, inter-process messaging services are typi- 
cally one of two messaging types: 

Function Based — uses the subroutine model of program- 
niing. The message interface is built upon the calling pro- 
gram passing the appropriate parameters and receiving the 
returned information. 

Message Based — message -based approach uses a defined 
message format to exchange information between processes. 
While a portion of the message may be unstructured, a 
defined header component is normally included. A message- 
based approach is not limited to the call/return structure of 
the function-based model and can be used in a conversa- 
tional manner. 

Core Messaging services are categorized by the charac- 
teristics of the information being transferred; 

File Transfer 

RPCs 

Message-Oriented Middleware 
Streaming 

How do Messaging services compare to Transaction Pro- 
cessing (TP) services? TP services ofEer broad functionality 
to support application management, administrative controls, 
and application-to-application message passing. TP services 
may include global transaction coordination, distributed 
two-phase commit, database support, coordinated recovery 
after failures, high availabiUty, security, and work load 
balancing. TP services may utilize Messaging services, 
which provide basic interprocess communication. 

Another category of Messaging services, SpeciaUzed 
Messaging services, includes services that extend Core 
Messaging services to provide additional functionality. 
Implementation Considerations 
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Is guaranteed delivery required? 

RPCs do not support guaranteed message delivery tech- 
niques such as store-and-forward and queuing. 
Consequently, RPCs depend upon the availability of the 
5 physical network and server processes. Therefore, network 
stabihty is important to consider when deciding to use RPCs. 

How important is flexibility? 

In general, RPCs work best with tightly coupled applica- 
tions or in environments where significant application modi- 
fications are unlikely. RPCs may be desirable if the appU- 
cation being developed is intended to be shrink wrapped and 
sold. 

Is synchronous or asynchronous program control 
required? 

Fimction based middleware such as RPCs traditionally 
provide synchronous program control. Therefore, they tend 
to pass control from the cUent process to the server process. 
When this occurs, the client is dependent on the server and 
must wait to perform any additional processing until the 
servers response is received. This type of program control is 
20 also known as blocking. Some RPC vendors are enhancing 
their products to support asynchronous program control as 
weU. 

What type of conversation control is required? 

RPCs permit one side of the conversation (the cUent) to 
25 only make requests, while the other side (the server) may 
only make replies. Conversation control is passed from the 
cUent to the server since the cUent, for each request, causes 
one or more functions to execute on the server while it waits 
for its reply. With RPCs, developers do not need to be 
concerned with the state of the conversation between the 
cUent and the server. In most cases, the absence of conver- 
sation states simplifies the design and development effort. 

Is ycUent interested in a stable or emerging technology? 

RPCs have existed for many years and are considered to 
be a mature, stable, proven solution. 

Is it important to minimize development complexity? 

Due to the synchronous program control and the request/ 
reply conversation control, RPCs can be fairly straightfor- 
ward to design and build. The complexity is also reduced 
since RPC caUs are completely independent of any previous 
40 or future RPC caU. On the other hand, RPCs usually require 
a specific RPC compiler, which may add to the development 
complexity. 

Are extended technical capabiUties required? 

If any of the foUowing capabiUties are required, message 
45 based middleware should be considered. It may also be 
possible to incorporate these capabiUties into a function 
based middleware solution, but significant custom modifi- 
cation and development may be required. 

Guaranteed DeUvery 

Store and Forward 

Queuing 

Priority Message Delivery 

Dynamic Routing 

Multicasting and Broadcasting 
55 Load Balancing 
Product Considerations 

What are the cUent's budgetary constraints? 

Costs may vary greatiy among middleware products. 
There are many factors to consider when looking at middle- 
60 ware, lb begin, middleware products can require extensive 
consulting and support services just to install. Therefore, 
understanding the set-up and configuration costs are impor- 
tant. There are also additional products required to complete 
an environment such as additional networking software 
65 which may be necessary for each individual client. In 
addition, development seat costs and production seat costs 
must considered. 
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Is synchronous or asynchronous communications 
required? 

All RPC products support synchronous program control. 
Some vendors are enhancing their prodxxcts to provide 
asynchronous capabilities as well. Asynchronous means that 
while information is being passed via send and receive 
commands, programs can continue to process other tasks 
while waiting for a response to a request. 

What^s the clients position on DCE? 

DCE software, developed by Open Systems Foundation 
(OSF), is hcensed to OSF-member companies to form 
products that provide common services. The RPC is one of 
several DCE common services. Some clients may desire to 
be aligned with DCE-based solutions. 

Is the middleware compatible with the other technology 
architecture components? 

Commimications middleware products must integrate 
with other technology architecture components, develop- 
ment tools, and operations tools. Therefore, it is necessary to 
understand the compatibility between these tools and the 
communications middleware product. 

Is it important for the product to support multiple plat- 
forms and operating systems? 

Hie middleware products must support the required com- 
puting platform such as Windows, UNIX, and Mainframe. It 
is common for vendors to claim that their product supports 
various platforms and operating systems, when in reality, 
that platform and operating system may be supported in a 
future release. It is important to request references of imple- 
mentations of the platforms and operating systems that are 
important to your specific environment. 

What is the client's vendor direction? 

When evaluating a middleware product, its important to 
consider the clients relationships with vendors in the tech- 
nology market. For example, if the client has a strong 
relationship with a vendor who is also in the middleware 
market, it would be wise to investigate and consider such a 
vendor for the clients middleware solution. 

Is it important for the product to support multiple network 
protocols? 

The middleware products must support the network pro- 
tocols such as TCP/IP, LU6.2, and IPX/SPX that are impor- 
tant to your specific environment. It is important to note that 
protocols can vary across platforms. Ensure that the clients 
specific transport protocol version is supported by the com- 
munications middleware product. For example, communi- 
cations middleware vendors may support TCP/IP but they 
may not support the particular TCP/IP vendor that the client 
has selected. 

Is a quick response time critical? 

RPC performance may vary between products based upon 
the internal mechanisms and techniques of the product. For 
example, slow performance may be due to the processing 
overhead associated with each RPC call. Some RPC prod- 
ucts may improve performance by utilizing special tech- 
niques used to invoke the server every time a client request 
arrives. Performance should be considered as a product 
differentiator. 

What level of security is required? 

There are potential security issues associated with the 
execution of commands on a remote system. Some vendors 
install security feattu'es into their products. It is also possible 
for the architecture team to build additional security into the 
overall solution. 

Is yclient interested in a stable or emerging product? 

Vendors should be evaluated on the quality of service they 
offer, their market share, the age of their product, the 
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installed base of their product, and their financial stability. In 
addition, since this market is stiU emerging, there are many 
small vendors in the market trying to offer solutions. Vendor 
and product stability should be taken very seriously. 
File Transfer 1530 

File Transfer services enable the sending and receiving of 
files or other large blocks of data between two resources. In 
addition to basic file transport, features for security, guar- 
anteed delivery, sending and tracking sets of files, and error 
logging may be needed if a more robust file transfer archi- 
tecture is required. The following are examples of FUc 
Transfer standards: 

File Transfer Protocol (FTP) allows users to upload and 
download files across the network. FTP also provides a 
mechanism to obtain filename, directory name, 
attributes and file size information. Remote fie access 
protocols, such as Network File System (NFS) also use 
a block transfer method, but are optimized for onhne 
read/write paging of a file. 

HyperText Transfer Protocol (HTTP)— Within a Web- 
based environment, Web servers transfer HTML pages 
to clients using HTTP HTTP can be thought of as a 
lightweight file transfer protocol optimized for trans- 
ferring small files. HTTP reduces the inefficiencies of 
the FTP protocol. HTTP runs on top of TCP/IP and was 
developed specifically for the transmission of hypertext 
between client and server. The HTTP standard is 
changing rapidly. 

Secure Hypertext Transfer Protocol (S-HTTP) — a secure 
form of HTTP, mostly for financial transactions on the 
Web. S-HTTP has gained a small level of acceptance 
among merchants sefiing products on the Internet as a 
way to conduct financial transactions (using credit card 
numbers, passing sensitive information) without the 
risk of unauthorized people intercepting this informa- 
tion, S-HTTP incorporates various cryptographic mes- 
sage formats such as DSA and RSA standards into both 
the Web client and the Web server. 

File Transfer and Access Management (FTAM) — ^The 
OSI (Open Systems Interconnection) standard for file 
transfer, file access, and file management across plat- 
forms. 

Implementation Considerations 

Additional options for File Transfer Services in a homo- 
geneous environment could include the native operating 
systems copy utility, Le. Windows NT Copy features. 
Possible Product Options 

Computer Associates CA-XCOM; Remote Ware; Hewlett- 
Packards HP FIAM; IBMs Files On-Demand gateway 
The following are examples of File Ttansfer products: 
Computer Associates CA-XCOM; Remote Ware; Hewlett- 
Packards HP FIAM; IBMs Files On-Demand gateway 
The foUoAving are examples of File Transfer products: 
Computer Associates' CA-XCOM — ^provides data trans- 
port between mainfirames, midrange, UNIX, and PC 
systems. XcelleNet's RemoteWare — retrieves, 
appends, copies, sends, deletes, and renames files 
between remote users and enterprise systems. Hewlett- 
Packard's HP FTAM — provides file transfer, access, 
and management of files in OSI networks. 
The following product provides File Transfer translation: 
IBM's Files On-Demand gateway — acts as a gateway 
between Web -based and mainframe-based FTP ser- 
vices to allow users to downbad mainframe-based files 
firom a World Wide Web browser. 
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RFC 1532 

RPCs (Remote Procedure Calls) are a type of protocol by 
which an application sends a request to a remote system to 
execute a designated procedure using the supplied argu- 
ments and return the result. RPCs emulate the function call 5 
mechanisms found in procedural languages (e.g., the C 
language). This means that control is passed from the main 
logic of a program to the called function, with control 
returning to the main program once the called function 
completes its task. Because RPCs perform this mechanism lo 
across the network, they pass some element of control from 
one process to another, for example, from the client to the 
server. Since the client is dependent on the response from the 
server, it is normally blocked from performing any addi- 
tional processing until a response is received. This type of 15 
synchronous data exchange is also referred to as blocking 
communications. 
Possible Product Options 

Sun Microsystems ONC+; OpenGroups DCE RPC; Novells 
NetWare RPC; NobleNet's EZ-RPC; Transarcs DCE 20 
RPC; Microsofts Windows95/NT RPC 
Sun Microsystems' ONC (Open Network Computing) 
OpenGroup's DCE (Distributed Computing 
Environment) 

NoveU*s NetWare RPC NobleNet EZrRPC Transarc's ^ 
DCE 

Microsoft's Windows95/NT RPC 
Message Oriented 1534 

Message-Oriented Middleware (MOM) refers to the pro- 
cess of distributing data and control throughout the 
exchange of records known as messages. MOM provides the 
application developer with a set of simple verbs (e.g., 
connect, send, receive, and disconnect) that are used to 
exchange information with other distributed apphcations. ^5 

Message-Oriented Middleware is responsible for manag- 
ing the interface lo the underlying communications archi- 
tecture via the commimications protocol APIs and ensuring 
the delivery of the information to the remote process. This 
interface provide the following capabilities: ^ 

Translating mnemonic or logical process names to oper- 
ating system compatible format 

Opening a communications session and negotiating 
parameters for the session 

Translating data to the proper format 45 

Transferring data and control messages during the session 

Recovering any information if errors occur during trans- 
mission 

Passing results information and status to the application. 

An application continues processing after executing a 
MOM request, allowing the reply to arrive at a subsequent 
time. Thus, unlike RPCs, MOM implements a "non- 
blocking" or asynchronous messaging architecture. 

Message-Oriented Middleware products typically support 
communication among various computing platforms (e.g., 
DOS, Windows, OS/2, Macintosh, UNIX, and mainfirames), 

IhtTC arc three types of Message-Oriented Middleware 
commonly implemented: 

Message Passing 

Message Queuing 

Publish and Subscribe 

Message Passing — as illustrated in FIG. 17, is a direct, 
application- to -application communication model. An appli- 
cation request is sent in the form of message from one 65 
application to another The communication method can be 
either synchronous like RPCs or asynchronous (through 
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callback routines). In a message-passing model, a direct link 
between two applications that participate in the message 
exchange is always maintained. 

Message Queuing (also known as Store and Forward) — as 
depicted in FIG. 18, is an indirect application lo application 
communication model that allows apphcations to commu- 
nicate via message queues, rather than by calling each other 
directly. Message queuing is asynchronous by nature and 
connectionless, meaning that the recipient need not be 
directly available when the message is sent. Moreover, it 
implies support for reliable, guaranteed and assured (non- 
dupUcatc) message deUvery. 

Publish and Subscribe (also known as Push messaging) — 
as shown in FIG. 19, is a special type of data dehvery 
mechanism that allows processes to register an interest in 
(i.e., subscribe to) certain messages or events. An applica- 
tion then sends (publishes) a message, which is then for- 
warded to all processes that subscribe to it. 
Implementation Considerations 

When trying to decide whether to use MOM technology, 
keep the following characteristics of this type of middleware 
in mind: 

MOMs are high speed, generally cormectionless and are 
usually deployed for executing applications with a 
nonblocking sender 

MOM solutions are especially useful for inter-application 
communication and are increasingly popular for inter- 
enterprise work 

MOMs support end-to-end business applications and pro- 
cess inter-operability 

MOMs are designed for heavily used production appli- 
cations and are generally capable of high throughput 
rates and fast transfer times. Data is usually forwarded 
immediately, although it is possible to store it for later 
processing 
Possible Product Options 

PeerLogics PIPES; IBM MQSeries; BEAs MessageQ; 
Momentum XIPC; Microsoft MQ (Falcon); TibCo's Ren- 
dezvous 

Message Passing 
PeerLogic's PIPES 

PIPES Platform applications communicate through a 
messaging interface that allows asynchronous, non- 
blocking communications. The messaging model is 
well-suited lo complex multi-lier applications because 
it inherently supports asynchronous, event-driven com- 
munications. 

Message Queuing 

IBM's MQSeries 

New features found in version 5 include: 

A new Internet gateway that allows customers and part- 
ners to run mission critical business applications over an 
unreliable network. 

Enhanced message distribution carries more business 
information, while minimizing use of networks. 

Performance improvements gives message transmission 
at least 8 times faster than previous versions 

Resource Coordination ensures that data held in databases 
is always updated completely— or not at all, if processing 
cannot complete. 

Additional developer features include fiirther language 
support for C++, Java and PL/1, and interoperability with 
current and previous MQSeries versions. 

Easier implementation because MQSeries now has the 
same install and use characteristics as other IBM Software 
Servers. 
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BEA's MessageQ 

Key highlights of the MessageQ product include: 

High performance — up to thousands of non-recoverable 
messages/second; hundreds of recoverable messages/second 

Both synchronous, and asynchronous message delivery 5 

Broadest platform support in the industry including 
UNIX, Windows NT, OpenVMS, and mainframes 

Common Application Programming Interface (API) 

Publish and subscribe (broadcasting) 

Microsoft Windows client product with support for DLLs lO 
(Dynamically Linked libraries), Visual Basic, and Power 
Builder development environments 

Message recovery on all BEA MessageQ clients and 
servers 

Interoperability with IBM MVS/CICS and IBM MVS/ 15 
IMS 

Large message size — up to 4 MB — eliminates need for 
message partitioning 
Momentum's XIPC 

XIPC is an advanced software toolset for the development '^^ 
of multitasking and distributed applications. XIPC pro- 
vides fault-tolerant management of guaranteed delivery 
and real-time message queuing, synchronization sema- 
phores and shared memory, all of which are network- 
transparent. ^ 
Microsoft Message Queue Server (MSMQ, formerly known 
as Falcon) 

Publish and Subscribe 

TibCo's Rendezvous 30 
TIB/Rendezvous' publish/subscribe technology is the 
foundation of TIBnet, HbCos solution for providing 
information deUvery over intranets, extranets and the 
Internet. It is built upon The Information Bus® (TIB®) 
software, a highly scaleable messaging middleware 35 
technology based on an event-driven publish/subscribe 
model for information distribution. Developed and 
patented by TIBCO, the event-driven, publish/ 
subscribe strategy allows content to be distributed on 
an event basis as it becomes available. Subscribers 40 
receive content according to topics of interest that are 
specified once by the subscriber, instead of repeated 
requests for updates. Using IP Multicast, TIBnet does 
not clog networks, but instead, provides for the most 
efficient real-time information delivery possible. 45 
Streaming 1536 

Streaming is the process of transferring time -sensitive 
data streams (e.g., video and/or audio) in real-time. Stream- 
ing differs from the other types of Core Messaging services 
in that it delivers a continuous, one-way stream of data, 50 
rather than the relatively short messages associated with 
RPC and Message -Oriented Middleware messaging or the 
large, batch transfers associated with File Transfer. (While 
the media stream is one-way from the server to the client, the 
client can issue stream controls to the server.) Streaming S5 
may be used to deliver video, audio, and/or other real-time 
content across the Internet or within enterprise networks. 

Streaming is an emerging technology. While some mul- 
timedia products use proprietary streaming mechanisms, 
other products incorporate standards. The following are eo 
examples of emerging standards for streaming protocols. 
Data streams are dehvcred using several protocols that are 
layered to assemble the necessary fimctionality. 

Real-time Streaming Protocol (RTSP) — RTSP is a draft 
Internet protocol for establishing and controlling 65 
on-demand delivery of real-time data. For example, 
clients can use RTSP to request specific media from a 
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media server, to issue commands such as play, record 
and pause, and to control media delivery speed. Since 
RTSP simply controls media delivery, it is layered on 
top of other protocols, s\ich as the following. 

Real-Time Transport Protocol (RTP) — ^Actual deUvery of 
streaming data occurs through real-time protocols such 
as RTP. RTP provides end-to-end data delivery for 
applications transmitting real-time data over multicast 
or unicast network services. RTP conveys encoding, 
timing, and sequencing information to allow receivers 
to properly reconstruct the media stream. RTP is inde- 
pendent of the underlying transport service, but it is 
typically used with UDP. It may also be xised with 
Multicast UDP, TCP/IP, or IP Multicast, 

Real-Tmie Control Protocol (RTCP)— RTP is augmented 
by the Real-Time Control Protocol. RTCP allows nodes 
to identify stream participants and communicate about 
the quahty of data delivery. 

The following table summarizes the protocol layering that 
supports Streaming: 



functionaHty 


sample protoool 
options 


architecture service 


controlling media 


RTSP or proprietary 


Streaming Messaging 


delivery 




service 


monitoring data stream KTCP or proprietaiy 


Streaming Messaging 






service 


end-to-end delivery 


RTP or proprietary 


Streaming Messaging 


of stream 




service 


message transport 


UDP, Multicast UDP, 


Message Transport 




TCP 


service 


packet forwarding/ 


IP, IP Multicast 


Packet Forwaiding/ 


internetworking 




Internetworking service 



FIG. 20 depicts Streaming, in which a real-time data 
stream is transferred. 
Possible Product OptionsOptions 

Netscape's Media Server; Progressive Networks Real 

AudioMdeo; VXtremes WebTheater 

The following are examples of products that implement 
Streaming Messaging (based upon RTSP or other standards 
or proprietary approaches): 

Netscape's Media Server 

Progressive Networks' Real Video VXtreme's WebThe- 
ater 

SpeciaUzed Messaging 1538 

Specialized Messaging services extend the Core Messag- 
ing services to provide additional functionality, including: 
Provides messaging among specialized systems by draw- 
ing upon basic messaging capabiUties 
Defines specialized message layouts 
Defines specialized inter-system protocols 
Suggests ways in which messaging draws upon directory 
and security services in order to deliver a complete 
messaging environment 
An example of a specialized messaging service is Mail 
Messaging. Mail Messaging is a specialized implementation 
of store-and-forwarding MOM (message-oriented 
middleware) messaging, in that Mail Messaging defines 
specialized, mail-related message layouts and protocols that 
utilize store-and-foTward messaging. 
E-Mail 1540 

E-Mail takes on a greater significance in the modem 
organization. The E-Mail system, providing it has sufficient 
integrity and stability, can function as a key diarmel through 
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which work objects move within, and between organizations 
in the form of messages and electronic forms. An E-Mail 
server stores and forwards E-Mail messages. Although some 
products like Lotus Notes use proprietary protocols, the 
following protocols used by E-Mail Services are based on 5 
open standards: 

X.400 — ^The X,400 message handling system standard 
defines a platform independent standard for store-and- 
forward message transfers among mail servers. X.400 is 
often used as a backbone e-mail service, with gateways 
providing interconnection with end-user systems. 

SMTP— Simple Mail Transfer Protocol (SMTP) is a 
UNIX/Internet standard for transferring e-mail among serv- 
ers. 

MIME — Multi-Purpose Internet Mail Extensions 
(MIME) is a protocol that enables Internet users to exchange 
multimedia e-mail messages. 

P0P3— Post OfiEce Protocol (POP) is used to distribute 
e-mail from an SMTP server to the actual recipient. 

IMAP4 — Internet Message Access Protocol, Version 4 
(IMAP4) allows a client to access and manipulate electronic 20 
mail messages on a server. IMAP4 permits manipulation of 
remote message folders, called "mailboxes", in a way that is 
functionally equivalent to local mailboxes. IMAP4 also 
provides the capability for an off-line client to 
re-synchronize with the server. IMAP4 includes standards 25 
for message handling features that allow users to download 
message header information and then decide which e-mail 
message contents to download. 
Implementation Considerations 

A number of E-mail servers from vendors including HP 30 
and Netscape are built arotmd SMTP, and most proprietary 
protocol E-Mail servers now provide SMTP gateways. 

The Multi-part Internet Mail Extensions (MIME) stan- 
dard has gained acceptance as the Internet mechanism for 
sending E-mail containing various multimedia parts, such as 35 
images, audio files, and movies. S/MIME, or secure MIME 
adds encryption and enables a secure mechanism for trans- 
ferring files. 

Although currently P0P3 is the popular Internet E-Mail 
message handling protocol, recently the lesser known 40 
IMAP4 protocol has been gaining in adoption among mail 
server and mail client software providers. IMAP was 
designed to add features beyond POP that allow users to 
store and archive messages and support mobile users that 
need to keep messages on a central server as well as on their 45 
laptop. 

Organizations are looking to use vehicles like E-Mail and 
the Intemet to enable communications with customers and 
trading partners. The least common denominator E-mail 
capability today is very rudimentary (ASCII text). But as the 50 
standards listed here as well as others become integrated into 
most of the popular E-maU products and gateways this wiU 
change enabling a more flexible and useful commercial 
comm\mications medium. 

Possible Product OptionsOptions 55 
Microsoft Exchange Server; Lotus cc:mail; Lotus Notes; 
Qualcomm Eudora; TenFours TPS Universal E-Mail 
Gateway; UUcoding; Netscape Mail Server; Posl.OflBcc; 
NTMail 

The following E-Mail products are based on the open eo 
Intemet standards defined above: 

Netscape Mail Server — ^Netscapes implementation of an 
open standards-based client/server messaging system 
that lets users exchange information within a company 
as well as across the Internet. It includes support for all 65 
standard protocols, and is packaged with Netscapes 
SuiteSpot server line. 
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Post.Offioe— one of the leading P0P3/SMTP mail servers 
for the Intemet community as well as corporate intra- 
nets. This message transport agent is based entirely on 
the open standards of the Internet, ensuring maximum 
compatibility with other systems. 

NTMail — an open SMTP and P0P3 mail server for 
Windows NT. 

The following are major proprietary E-mail servers used 
in large organizations today: 
Lotus Notes — ^platform-independent client/server mail 
system. Notes Mail can support over 1,500 active users 
per server, offering Intemet integration, distributed 
replication and synchronization. Lotus Notes also pro- 
vides integrated document libraries, workflow, calen- 
daring and scheduling, and a cc:Mail user interface. 
Microsofts Exchange Server — Exchange 4.0 provides a 
messaging and groupware platform to support collaboration 
solutions on Windows machines. Microsoft Exchange 5.0 
has support for all of the key Intemet protocols. These 
include P0P3 for mailbox access, SMTP for mail sending 
and receiving, NNTP for newsgroups and discussion 
forums, LDAP for directory access, HTTP and HTML for 
access via a web browser, and SSL for security. 
The following products are examples of e-mail systems: 
Microsoft Mail 
Lotus cc:mail 
Qualcomm Eudora 

The following products provides e-mail system transla- 
tion: 

TenFour^s TPS Universal E-Mail Gateway — blinks users 
of Lotus Development Corp.'s cc:Mail and Notes, 
Novell Inc.'s GroupWise, Microsoft Corp.'s Mail, Md 
Mail, and SMTP e-mail to Microsoft Exchange. 
UUcoding — process for converting 8-bit binary files into 
7-bit ASCII files for transmission via e-mail over the 
Intemet (the Intemet only supports seven bit characters 
in e-mail messages); UUencode and UUdecode utilities 
on end nodes perform the conversion. 
Database Access 1542 

Database Messaging services (also known as Database 
Access Middleware) provide connectivity for clients to 
access databases throughout the enterprise. Database mes- 
saging software draws upon basic inter-process messaging 
capabilities (e.g., RPCs) in order to support database con- 
nectivity. Database Messaging services typically provide 
single application seemless access to mulitple data sources, 
both relational and non-relational. Additionally, database 
messaging services can be used to fadUtate migration of 
data from one environment to another (i.e., MVS/DB2- 
-*Sybase) 

There are three types of database access middleware: 

ODBC-like 

Propietary 

Gateway 

Is there a projected growth in data requirements? 

Storage of data in a database allows for more optimal 
future growth since databases scale better than mechanisms 
such as flat files. 

Shoxild the data be secured and controlled? 

Use databases to protect data integrity from multiple user 
access, and hardware and software failures. 

Is it desirable to limit the amount of viewed data? 

Use databases to store large amounts of informadon and 
to access an individual rccord(s) without having to inspect 
all the records of a given topic. 



06/17/2004, EAST Version: 1.4.1 



us 6,6: 

75 

Is there a need to impose data standards? 

Use a database when you wish to store and impose 
standards on data elements. This is important when devel- 
oping enterprise wide solutions, since it is desirable to have 
the different applications access the same structured infor- 
mation. 

Is there a current or potential requirement for a distributed 
architecture? 

Databases allow for the potential of such architectural 
features as a data replication strategy and/or distributed data 
access. 

Is there a need to minimize data duplication? 

Because of their normalized design, relational databases 
are used to reduce data redundancy. This reduces mainte- 
nance and storage requirements. 
Product Considerations 

What are the available administration or systems man- 
agement features? 

Administration and systems management features such as 
remote management, remote configuration, backup and 
recovery, and disaster recovery should be considered. 

What are the key business requirements? 

Product selection may be influenced by business require- 
ments such as replication and distributed data, parallel 
processing, complex object support for such purposes as 
multimedia, OLTP, decision support, VLDB, data 
warehousing, and availability (24/7 vs. 8/5). 

What is the availability of market resources to support the 
product? 

Personnel available for support (permanent hires, 
contractors), and third party support for skilled resources/ 
training should be considered. 

Are the current data requirements expected to increase? 

Products differ in their ability to scale with respect to 
hardware architecture, transaction throughput, and user 
base. 

How do the vendors compare against one another? 

Issues to consider are type, quality and responsiveness of 
support, alhances/partnerships with other companies, mar- 
ket presence (install base, customer list, number of produc- 
tion copies, etc.), vendor industry, alignment of mission and 
vision with that of potential customer/evaluator, product 
philosophy, long-term product plans/strategy, and vendor's 
training. 

How well does a product integrate with the current or 
proposed architecture? 

Issues to consider include supported operating systems, 
networks, and other database platforms, availability of data- 
base utilities, application interfaces, development tools, and 
third party products, and integration with legacy systems. 
Possible Product Options 

Oracles SQL* Net; Sybases Enterprise Connectivity; 

Microsoft's Open Database Connectivity (ODBC); Sun 

Java Database Connectivity (JDBC) 

Oracle's SQL* Net — supports database interoperability 
across a variety of transport protocols (e.g., TCP/IP, 
SPX/IPX, SNA, etc.); includes verbs such as connect, 
send, receive, and disconnect; performs transparent 
protocol bridging by allowing multiple protocols to 
reside simultaneously on each node. 

Sybase's Enterprise Connectivity — supports database 
interoperability across a variety of platforms. 

Microsoft's Open Database Connectivity (ODBQ — a 
database programming interface that provides a com- 
mon language for Windows applications to access 
databases on a network. 

Sun*s Java Database Connectivity (JDBC) — a Java-based 
programming interface that provide a common method 
for Java applications to access databases on a network. 
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Object Messaging 1544 

Object Messaging enables objects to transparently make 
requests of and receive responses from other objects located 
locally or remotely. Objects communicate through an Object 

5 Request Broker (ORB). An ORB enables client objects to 
access server objects either locally or remotely over a 
network and invoke operations (i.e. functions and methods) 
on them. ORBs typically provide interoperability between 
heterogeneous client and server environments: across lan- 

10 guages and/or operating systems and/or network protocols. 
In that respect some have said that ORBs will become a kind 
of "ultimate middleware" for truly distributed processing. A 
standardized Interface Definition Language ^DL) defines 
the interfaces that applications must use to access the ORB 

15 Services. Hie two major Object Request Broker standards/ 
implementations are: 

Object Management Group's Common Object Request 

Broker Architecture (CORBA) 
Microsoft's (Distributed) Component Object Model 

20 (COM/DCOM) 
CORBA 

Common Object Request Broker Architecture (CORBA) 
is a standard for distributed objects being developed by the 
Object Management Group (OMG). The OMG is a consor- 

25 tium of software vendors and end users. Many OMG mem- 
ber companies are developing commercial products that 
support the CORBA standards and/or are developing soft- 
ware that use these standards. CORBA provides the mecha- 
nism by which objects transparently make requests and 

30 receive responses, as defined by OMG's Object Request 
Broker (ORB). The CORBA ORB is an application frame- 
work that provides interoperability between objects, built in 
different languages, running on different machines in het- 
erogeneous distributed environments, 

35 Inter-ORB Messaging 

The OMGs Internet Inter-Orb Protocol (HOP) specifies a 
set of message formats and common data representations for 
communication between ORBs over TCP/IP networks. 
CORBA-based Object Messaging is summarized in FIG. 21. 

40 COM/DCOM 

Component Object Model (COM) is a client/server 
object-based model, developed by Microsoft, designed to 
allow software components and applications to interact with 
each other in a uniform and standard way. The COM 

45 standard is partly a specification and partly an implementa- 
tion. The specification defines mechanians for creation of 
objects and commimication between objects. This part of the 
specification is paper-based and is not dependent on any 
particular language or operating system. Any language can 

50 be used as long as the standard is incorporated. The imple- 
mentation part is the COM library which provides a number 
of services that support a mechanism which allows appli- 
cations to connect to each other as software objects. COM 
is not a software layer through which all communications 

55 between objects occur. Instead, COM serves as a broker and 
name space keeper to connect a client and an object, but 
once that connection is established, the client and object 
communicate directly without having the overhead of pass- 
ing through a central piece of API code. Originally con- 

60 ceived of as a compound document architecture, COM has 
been evolved to a full object request broker including 
recently added features for distributed object computing. 
DCOM (Distributed COM) contains features for extending 
the object model across the network using the DCE Remote 

65 Procedure Call (RPC) mechanism. In sum, COM defines 
how components should be built and how they should 
interact. DCOM defines how they should be distributed. 
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Currently COM/DCOM is only supported on Windows- CTI Server/Workstation-based or Host-based API 
based machines. However, third-party vendors arc in Products — operate on aparticular computer vendor's 
progress of porting this object model to other platforms such hardware platform and provide call control and mes- 
as Macintosh, UNIX, etc. FIG. 22 illustrates COM Messag- saging functionality. 

. o -J *• ^ CTI Cross-Platform Vendors — products that have been 

Implementation Considerations . . . w i i. j. wr / *• 

u rMir> -J L • r ^ .1 ported to multiple hardware platforms/operating sys- 

Although ORBs provide a mechanism for transparently ^ *^ r "> f & j 

commimicating among components located locally or ^^'^ . o . ^ ^ ^ . ^ 

remotely, performance issues need to be thoroughly ^ Solutions-focus solely on call control 

addressed before moving components around the network and caiyapplication synchronizaUon ^f^ 

Making requests and receiving responses among compo- '° ^ Enterprise SolutioDS-i)rovide all CU business 

nents located on different machines will take longer that ^ .ki^^*""^* o Tf"^"^^ 

having the same communication between components Possible Product O^ons , 

located on the same machine. Performance is dependent on ^^^^^ ^ ^l^^^ Telephony Services; Microsoft T^I; 

what type of network is available (LAN, type of LAN, NoveUTSAPl . . ^ 

WAN, type of WAN, dial-up, wireless, etc.), size of mes- Industry-Standard ApphcaUon Programmmg Interfaces 

sages and number of messages that go across the network. (APIs). 

Possible Product Options Microsoft's TAPI 

Expersoft's CORBAplus; IBM's Component Broker; BEA- Novell's TSAH 

Systems ObjectBroker; lona Technology's Orbix; ^ Novell's Netware Telephony Services — Based on Nov- 

Inprise's Visibroker; Microsofts COM; Software AGs ell's Telephony Services API (TSAPI), Netware 

COM Telephony Services is a CTI gateway that integrates 

CORBA-based ORB products Novell networks with telephony networks. 

Expersoft's CORBAplus Other vendors of CTI products include: 
IBM's Component Broker 25 Aspect Telecommunications Corp. 

BEA's Object Broker Genesys Labs 

lona Technologies's Orbix IBM 

Inprise's VisiBrok6r(formerly Visigenic) Lucent 

COM products ^^^^^^ 
Microsoft's DCOM (Windows NT Server, Windows NT ^ p w 11 

Workstation, Windows 95, Apple Macintosh, Windows rxM^T^ • 1 ^aq 

Java Virtual Machine) Messagmg 154» 

o ^^*-r^ . 1 J M L.^.. EDI (Electronic Data Interchange) supports system-to- 

Software AG s COM (am^nt or pknned availabdity on ^ners by defining 

Sim, Digital UNIX, IBM, and HP platforms) message layouts CompaniJtypically use EDI t^ 

agi^ streamline commercial transactions within their supply 

Computer-Telephone Integration (CTI) integrates com- chains 

puter systems and telephone systems tocoordinate dau and EDI standards (e.g., EDIFACT, ANSI X12) define record 

telephony activmes. For example, CTI can be used to j js for transactions such as "purchase orders". EDI 

assoaate a customers database entry with the customers services include the generation and translation of EDI mes- 

lelephone call and route tibe caU accordmgly. « ^^^^ing to the various pubUc message layout stan- 

Referrmg to FIG. 23, Cn Messagmg supports commu- * 

A^^w'l"! mT..^""' ^ ^^^i EDImessagingcanbeimplementedviaelectionicmailor 

ACDs 2304, hybrid pktforms, networks 2306, and external ^^mized mlssage-oriented architectures. 

^i^«^ !or%^^'''"'^?«'^i'™''''°°'"°^''^*'^ 45 Implementation Considerations 

PBX/ACD APIs, cn vendor-speciflc APIs or message sets, ^^^^ traditionally been sent between com- 

andmdustry-standard APIs. ^^^^ ^j^^ ^ ^^^^ ^^^^ Network). VANs have 

Cll Messapng has two primary tunctions: (^^^^ criticized for their relatively high cost in comparison to 

Device-specific communication p^^Uc networks like the Internet. Recently, EDI messaging 

Manages direct communications between telephony vendors such as Premenos have been creating software with 

devices and data devices built-in encryption features to enable companies to send EDI 

Allows applications to control PBXs, key telephone transmissions securely over the Internet. 

systems, ISDN, analog PSTN, cellular, Centrex, etc. Web server vendors including Microsoft, Netscape and 

and supports features such as address translation, call OpenMarket are putting plans in place to add EDI transmis- 

setup, call answering, call dropping, and caller ID. sion capabilities into their Web server products. OpenMarket 

Provides interface to carrier networks for call delivery and Inc. is working with Sterling and Premenos to integrate their 

call-related messaging EDI management software with OpenMarkets OMTransact 

Message mapping electronic commerce server software. Netscape is working 

Translates devicc-spedfic communication to generic API with GEIS in creating Actra Business Systems to integrate 

and/or message set 60 services with Netscape server products, 

cn products can be divided into the following categories: Possible Product Options 

cn Platform-Specific Products-Products that can only ^^^^ Equipment Corp.s DEC/EDI; SterUng Commerces 

be implemented on the hardware of a specific vendor. GENTRAN; IBM Global Services Advantis; GE Infor- 

Cn Telephony-based API Products-Include propri- mation Services; Sterling Commerce 
etaryPBX/ACD-based messaging sets, which permit 65 EDI Applications 

external devices to interface with the vendor's PBX/ Digital Equipment Corp.'s DEC/EDI 

ACD call and station control logic Sterling Commerce's GENTRAN 
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EDI value-added networks (VANs)— VANs Unk EDI 
trading partners and transmit EDI messages through a 
central electronic clearinghouse 

IBM Global Services' Advantis 

GE Information Services 

Sterling Commerce 
Legacy Integration 1550 

Legacy services provide gatewarys to mainframe legacy 
systems. The following protocol is typically used: 

Systems Network Architecture (SNA) is a networking 
connection-oriented protocol architecture which was 
developed in the 1970s by IBM. Currently, SNA and 
TCP/IP are two of the most widely used networking 
protocol architectures. 

Design techniques for integration with existing systems 
can be grouped into two broad categories: 

Front end access — discussed as part of Terminal Emula- 
tion 

Back end access — tend to be used when existing data 
stores have information that is needed in the client/ 
server environment but accessing the information 
through existing screens or functions is not feasible. 
Legacy Integration messaging services typically 
include remote data access through gateways, A data- 
base gateway provides an interface between the client/ 
server environment and the legacy system. The gate- 
way provides an ability to access and manipulate the 
data in the legacy system. 
Implementation Considerations 

Legacy systems hold critical data which must be acces- 
sible by new Netcentric computing solutions. These legacy 
data sources often must be accessed in their current form so 
as to not disrupt the legacy systems. 
Communications Security 1508 

Communications Security services control access to 
network-attached resources. Combining network Security 
services with security services in other parts of the system 
architecture (e.g., application and database layers) results in 
robust security. 
Possible Product Options 
UkWeb's Stronghold; UkWeb's SafePassage 
UkWeb's Stronghold 

Stronghold was the first web server to support SSL Chenl 
Authentication. Regular expression-based matching of cli- 
ent certificate information to determine access control is 
possible. Stronghold also has an API for certificate to 
usemame mapping so that client certificates may be mapped 
to standard usemames. CA certificates from both Thawte 
and Verisign can be utilized. Uncompromised, full 128-bit 
symmetric encryption is provided in all versions. This 
provides Netcentric systems used outside of the USA or 
Canada with secure encryption capabilities. 
UkWebs^s SafePassage 

SafePassage is a full-strength, encrypting Web proxy. It is 
designed to supplement the security of browsers whose 
authentication and encryption capabilities have been weak- 
ened to comply with United States export regulations. For 
these types of browsers, SafePassage will provide client 
authentication certificates and full-strength encryption (12S 
bit). 

Encryption 1552 

Encryptbn services encrypt data prior to network transfer 
to prevent unauthorized interception. (Note that encryption 
can occur within the Communications Services layer, the 
Transport Services layer, or the Network Media Services 
layer.) Within die Communications Services layer, encryp- 
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tion occurs at the top of the protocol stack: and is typically 
performed within an application (e.g., an e-mail application, 
a Web browser). Tliis is an end-to-end approach that can 
leave the remainder of the protocol stack (i.e., the Transport 
5 services and the Network Media services) unaffected. 

Encryption has two main components: the encryption 
algorithm, which is the series of steps that is performed to 
transform the original data; and the key, which is used by the 
algorithm in some way to encrypt the message. TVpically, 
10 the algorithm is widely known, while the key is kept secret. 
There are several types of encryption intise today, including: 
Secret key cryptography — uses one key (the secrei key) 
both to encrypt the message on one side and to decrypt 
the message on the other side. 
Public key cryptography — uses two keys, the public key 
and the private key. The pubHc key and private key are 
mathematically related so that a message encrypted 
with the recipient's public key may be decrypted with 
the recipient's private key. Therefore, the public key 
^ can be widely published, while the private key is kept 
secret. 

Hiere are also varying methods of employing encryption 
types described above to encrypt data sent across a network: 
Data link layer — data is encrypted before it is placed on 
^ the wire. Data Unk encryptors are generally hardware 
products. 

Application layer — data is encrypted by the application. 
Netscape's Secure Sockets Layer (SSL) is one example 
^ of application-layer encryption for VWW browsers. 
SSL uses RSA encryption to wrap security information 
around TCP/IP based protocols. 
Network layer — data is encrypted inside the network 
layer header, therefore relying on the network layer 
35 protocol 

Implementation Considerations 

The advantage of SSL over S/HTTP is that SSL is not 
restricted to HTTP but can also be used for securing other 
TCP/IP based services such as FTP, Telnet, etc. SSL can 
4Q provide session level data encryption and authentication to 
enable secure data communications over public networks 
such as the Internet. 

The need for Encryption Services is particularly strong 
where electronic commerce solutions that involve exchang- 
45 ing sensitive or financial data are to be deployed over public 
networks such as the Internet. Cryptography can be used to 
achieve secure communications, even when the transmission 
media (for example, the Internet) is tmtnistworthy. Encryp- 
tion Services can also be tised to encrypt data to be stored 
50 (c-g'j sensitive product information on a sales person's 
laptop) to decrease the chance of information theft. 

There are complex legal issues surrounding the use of 
encrypting in an international environment. The US govern- 
ment restricts what can be exported (in terms of encryption 
55 technology), and the French government defines encryption 
technology as a "weapon of war" with appropriate legal and 
regulatory restrictions. This is a key issue in international 
e-commerce today. 
Possible Product Options 
go Netscape's Secure Sockets Layer (SSL); S-HTTP; e-mail 
encryption; S-MIME 
Encryption that is architected into Web-based solutions 
Netscape's Secure Sockets Layer (SSL) — ^provides 
encryption for World Wide Web browsers. 
65 S-HTIP— a secure version of the HTTP data transfer 
standard; used in conjunction with the World Wide 
Web. 
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Encryption that is embedded in e-mail products 
e-mail encryptioa — products such as Lotus Notes and 
Microsoft Exchange can encrypt e-mail messages and/ 
or attachments. 
S-MIME — a secure version of the MIME e-mail standard. 
Authorization 1554 

When a user requests access to network resources, the 
Authorization service determines if the user has the appro- 
priate permissions and either allows or disallows the access. 
(This occurs after the user has been properly authenticated.) 

The following are examples of ways to implement Autho- 
rization services: 

Network Operating Systems — Authorization services are 
bundled with all network operating systems in order to 
control user access to network resources. 
Firewall Services protect sensitive resources and infor- 
mation attached to an Intxxnet network from unautho- 
rized access by enforcing an access control policy. A 
variety of mechanisms exist for protecting private 
networks including: 

Filters — World Wide Web filters can prevent users from 
accessing specified content or Internet addresses. 
Products can limit access based on keywords, net- 
work addresses, time-of-day, user categories, etc. 

Application Proxies — ^An application-level proxy, or 
application-level gateway, is a robust type of fire- 
wall. (A firewall is a system that enforces an access 
control policy between a trusted internal network and 
an untrusted external network.) The application 
proxy acts at the appUcation level, rather than the 
network level. The proxy acts as a go-between for 
the end-user by completing the user-requested tasks 
on its own and then transferring the information to 
the user. The proxy manages a database of allowed 
user actions, which it checks prior to performing the 
request. 

Servers, Apphcations, and Databases — Authorization can 
occur locally on a server to limit access to specific 
system resources or files. Apphcations and databases 
can also authorize users for specific levels of access 
within their control. (This functionality is within the 
Environment Services grouping in the execution 
architecture.) 
Possible Product Options 

Microsoft Windows NT, Novell Netware; UNIX; Check 
Points Firewall- 1; Raptor Systems Eagle Firewall; 
Microsoft Proxy Server; Netscape Proxy Server; Micro- 
system Softwares Cyber Patrol Corporate; Net Nanny 
Softwares Net Narmy 
Network Operating Systems 

Microsoft Windows NT, Novell Netware, UNIX, etc. 
AppUcation Proxies 
Microsoft Proxy Server — allows for designation of who 
can access the Internet and which services they can use. 
Administrators can establish additional credentials for 
logging on, set specific diahng hours or days of the 
week, and restrict access to certain sites altogether. 
Netscape Proxy Server — ^high-performance server soft- 
ware for replicating and filtering access to Web content 
on the Internet or an intranet. Provides access control, 
URL filtering, and virus scanning. 
Filters 

Check Point FireWall-1 — combines Internet, intranet and 
remote user access control with strong authentication, 
encryption and network address translation (NAT) ser- 
vices. The product is transparent to network users and 
supports multiple protocols. 
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BorderWare Firewall — protects TCP/IP networks from 
unwanted external access as well as provides control of 
internal access to external services; supports packet 
filters and application-level proxies. 

Raptor System's Eagle Firewall 

Microsystem Software's Cyber Patrol Corporate 

Net Nanny Software's Net Nanny 
Authentication 

Authentication services verify network access requests by 
validating that users are who they claim to be. For secure 
systems, one or more authentication mechanisms can be 
used to validate authorized users and to verify which func- 
tions and data they have access to. Within the corporate 
network, authentication services are often included in direc- 
tory services products like Novell's NDS. NDS requires the 
user to have an established account and supply a password 
before access is granted to resources through the directory. 
- Authentication for accessing resources across an Internet 
or intranet is not as simple and is a rapidly evolving area. 
When building e-commerce Web sites there may be a need 
to restrict access to areas of information and functionality to 
known customers or trading partners. More granular authen- 
tication is required where sensitive individual customer 
account information must be protected from other custom- 
ers. 

Authentication can occur through various means: 
Basic Authentication — requires that the Web client supply 
a user name and password before servicing a request. 
Basic Authentication does not encrypt the password in 
any way, and thus the password travels in the clear over 
the network where it could be detected with a network 
sniffer program or device. Basic authentication is not 
secure enough for baiiking applications or anywhere 
where there may be a financial incentive for someone 
to steal someone's account information. Basic authen- 
tication is however the easiest mechanism to setup and 
administer and requires no special software at the Web 
client. 

ID/Password Encryption — offers a somewhat higher level 
of security by requiring that the user name and pass- 
word be encrypted during transit. The user name and 
password are transmitted as a scrambled message as 
part of each request because there is no persistent 
coimection open between the Web client and the Web 
server. 

Digital Certificates or Signatures — encrypted digital keys 
that are issued by a third party "trusted" organization 
(i.e. Verisign); used to verify user's authenticity. 

Hardware tokens— small physical devices that may gen- 
erate a one-time password or that may be inserted into 
a card reader for authentication purposes. 

Virtual tokens — typically a file on a floppy or hard drive 
used for authentication (e.g. Lotus Notes ID file), 

Biometric identification — the analysis of biological char- 
acteristics to verify individuals identify (e.g., 
fingerprints, voice recognition, retinal scans). 

Related to authentication, non-repudiation is a means of 
tagging a message in order to prevent an entity from denying 
that it sent or received the message. 
Possible Product Options 

Microsoft Windows NT; Novell NetWare; UNIX; Platinum 
Technologies AutoSecure SSO; Axents Enterprise Access 
Control for Windows 95; SecurlD; Racals TrustMe 
Authentication Server; Visionics Facelt; Sensars Irisldent; 
Kcyware Technologies Voice Guardian; National Regis- 
trys NRIdcntity; Kerberos; VeriSign 
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The following arc examples of products that perform 
authentication: 
user IDs and passwords 

operating systems: Microsoft Windows NT, Novell 

NetWare, UNIX, etc. 
application level user IDs and passwords (e.g., e-mail 

system) 

single sign-on software — manages user logins to multiple 
systems or resources. 

Platinum Technologies* AutoSecure SSO 
add-on administration packages — enhance the capabiUties 
of native operating system security. 

Axent's Enterprise Access Control for Windows 
95 — enforces password standards and encrypts data. 
Hardware Tokens 

Security Dynamics' SecurlD Authentication Tokens 

Racal's TrustMe Authentication Server 
Biometric Security 

\^sionics' Facelt — ^face recognition 

Sensar's Irisldent — ^iris identification 

Keyware Technologies* Voice Guardian — ^voice recogni- 
tion 

National Registry's NRIdeotity — fingerprint recognition 
Keys and Certificates 

Kerberos — an encryption and key management protocol 
for third party authorization; vendors include Cyber- 
SAFE and Digital Eqmpment Corporation. 

Verisign — a company that manages digital certificates. 
Communication Fabric 1010 

As communication networks become increasingly com- 
plicated and interconnected, the services provided by the 
network itself have by necessity increased as well. Clients 
and servers are rarely directly connected to one another, but 
separated by a network of routers, servers and flrewaUs 
providing an ever increasing number of network services 
such as address resolution, message routing, security screen- 
ing and many more. 

The commimications fabric provides common network 
services to the platform-specific network services residing 
on the client and server nodes. These common network 
services can be used to manage resources and translate 
capabilities within and across enterprises. 

Short of interpreting the data being transmitted, the com- 
munications fabric is aware of the different message- 
oriented information streams in order to help the ctient and 
server communicate regardless of the different network 
functions implemented on each platform. 

An inteUigent commiinications fabric monitors and routes 
data flows and provides functionality (security, directories, 
etc.) to cUents and servers. An intelligent communications 
fabric provides the following benefits: 

An intelligent network can manage itself, including 
addressing, routing, security, recovery, etc. It is ineffi- 
cient for individual clients and servers to perform such 
tasks. 

Specialized network components reduce the network- 
related processing that occurs on chents and servers. 

An intelligent network integrates heterogeneous chents, 
servers, and other resources by resolving incompatible 
protocols and standards. 

An inteUigent network has the capabiUty to actively 
manage the flow of information rather than simply 
moving data. This allows the network to effectively 
deliver multimedia and other network-sensitive traffic. 



An intelligent network adds value to enterprise resources 
by presenting a cohesive view of available resources 
and increasing the level of security associated with 
those resources. 
5 FIG. 24 illustrates various components of the Communi- 
cation Fabric. 
Transport Services 2402 

Provides the underlying protocols responsible for trans- 
mitting and securing data communications. Transport Ser- 
10 vices are responsible for establishing, maintaining and ter- 
minating end-to-end commxmications between users and 
processes. Connection management provides transfer ser- 
vices that ensure the delivery of data from sender to receiver, 
which support the transfening of messages fi'om a process 
1^ running on one machine to a process running on another 
machine. In addition, connection management provides ser- 
vices that initiate a connection, gracefully terminate a 
connection, and handle abrupt termination. These services 
take place for application before and after the data is 
20 formatted for transport over the network. 
Messaging TYansport 2404 

The Message Transport service is responsible for the 
end-to-end delivery of messages. It can include the follow- 
ing functionahty: 
25 End-to-End Data Transfer — ^The Message Transport Ser- 
vice formats messages for sending and confirms the 
integrity of received messages. 
Connection Control — The Message Transport service 
may establish end-to-end (chent-server) connections 
30 and track addresses and other associated information 
for the cormection. The service also tears down con- 
nections and handles hard connection faflures. 
Reliable Transfer — ^The Message Transport service may 
manage reliable deUvcry of messages through the use 
35 of acknowledgments and retransmissions. 

Flow Control — ^The Message Transport service may aUow 
the receiver to govern the rate at which the sender 
transfers data. 

Multiplexing — ^The Message Transport service may 
define multiple addresses or ports within a single 
network node, allowing multiple processes on the node 
to have their own communications paths. 
(Some transport services do not implement all of the fisted 
functionality. For example, the UDP protocol does not offer 
connection control or reliable transfer.) 

The following are examples of protocols that provide 
message transport: 

SPX (Sequenced Packet exchange) 
TCP (Transmission Control Protocol) 
UDP (User Datagram Protocol) 
NetBIOS/NetBEUI (Network Basic Input/Output 

System/NetBIOS Extended User Interface) 
APPC (Advanced Program-to-Program Commxmications) 
ss AppleTalk 

Packet Forwarding/Internetworking 2406 

The Packet Forwarding/Internetworking service transfers 
data packets and manages the path that data takes through 
the network. It includes the following functionality: 
60 Fragmentation/Reassembly — ^The Packet Forwarding/ 
Intemetworking service divides an application message 
into multiple packets of a size suitable for network 
transmission. The individual packets include informa- 
tion to allow the receiving node to reassemble them 
65 into the message. The service also validates the integ- 
rity of received packets and buffers, reorders, and 
reassembles packets into a complete message. 
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Addressing — The Packet Forwarding/Internetworking 
service encapsulates packets with addressing informa- 
tion. 

Routing — ^The Packet Forwarding/Intemetworking ser- 
vice can maintain routing information (a view of the 
network topology) that is used to determine the best 
route for each packet. Routing decisions are made 
based on the cost, percent utilization, delay, reliability, 
and similar factors for each possible route through the 
network. 

Switching — Switching is the process of receiving a 
packet, selecting an appropriate outgoing path, and 
sending the packet. Switching is performed by routers 
and switches within the communications fabric. 
Switching can be implemented in the following ways: 
For some network protocols (e.g., IP), routers draw 
upon dynamic routing information to switch packets 
to the appropriate path. This capability is especially 
important when connecting independent networks or 
subnets. 

For other network protocols (e.g., Ethernet, Token 
Ring), switching simply directs packets according to 
a table of physical addresses. The switch can build 
the table by "listening" to network traffic and deter- 
mining which network nodes are connected to which 
switch port. 

Some protocols such as Frame Relay involve defining 
permanent routes (permanent virtual circuits PVCs) 
within the network. Sinc3e Frame Relay is switched 
based upon PVCs, routing functionality is not 
required. 

Multicasting — ^The Packet Forwarding/Intemetwotking 
service may support multicasting, which is the process 
of transferring a single message to multiple rcc:^ients 
at the same time. Multicasting allows a sender to 
transfer a single copy of the message to the communi- 
cations fabric, which then distributes the message to 
multiple recipients. 

The following are examples of protocols that provide 
Packet Forwarding/Internetworking: 

IP (Internet Protocol) 

IP Multicast (emerging standard that uses a special range 
of IP addresses to instruct network routers to deliver 
each packet to all users involved in a multicast session) 

IPX (Internetwork Packet Exchange) 

ATM (Asynchronous Transfer Mode) 

Frame Relay 

X.25 

SMDS (Switched Multimegabit Data Service) 
The following are examples of network components that 
perform Packet Forwarding/InterDetworking: 
routers 
switches 

ATM switches. Frame Relay switches, IP switches, Eth- 
ernet switches. Token Ring switches, etc. 

The following are examples of protocols that maintain 
routing information tables within routers: 

Distance Vector Protocols — each router periodically 
informs neighboring routers as to the contents of rout- 
ing table (destination addresses and routing metrics); 
routing decisions based on the total distance and other 
"costs" for each path. 

IP and IPX Routing Information Protocols (RIP) 
Apple Talk Routing Table Management Protocol 
(RTMP) 
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Ciscos Interior Gateway Routing Protocol (IGRP) and 
Enhanced IGRP 
Link-State Protocols— each router periodically broad- 
casts changes to the routers and directly attached net- 
5 works that it can talk with. 

Open Shortest Path First (OSPF) 
ISOs Intermediate System to Intermediate System 
(IS— IS) 

Novells NetWare Link Services Protocol (NLSP) 
Policy Routing Protocols — allow Internet backbone rout- 
ers to accept routing information from neighboring 
backbone providers on the basis of contracts or other 
non-technical criteria; routing algorithms are Distance 
Vector. 

15 Border Gateway Protocol (BGR) 

Interdomain Routing Protocol (IDR) 
Circuit Switching 2408 

While Message Transport services and Packet 
Forwarding/Internetworking services support the transfer of 
2° packetized data. Circuit Switching services establish physi- 
cal circuits for the transfer of circuit-switched voice, fax, 
video, etc. 
Circuit Switching 
uses an end-to-end physical oonnectbn between the 
^ sender and the receiver that lasts for the duration of the 
"call" 

includes voice, video, fax, etc. 

includes data in a circuit switched architecture (e.g., 
3Q dial-up cormections) 
Packetized 

transferred through brief, temporary, logical connections 
between nodes includes data and packetized multime- 
dia (video, voice, fax, etc.) 
35 Circuit Switching includes the following functionality: 

establishes end-to-end path for circuit (may involved 
multiple intermediate nodes/switches) 

manages end-to-end path (quality, billing, termination, 
etc.) 

40 The following are examples of Circuit Switching: 
analog dial-up telephone circuit 
ISDN (Integrated Services Digital Network) 
Possible Product Options 

Lucent's Definity; Nortels Meridian; Lucents ESS; Nortels 
45 DMS; Tellabs Titan Products; Lucents DSX Products; 
Alcatels SX Products; AltiGens AltiScrv; Lucents Interact 
Telephony Server 

The following are examples of PBX products, which 
perform circuit switching within private telephone net- 
50 works: 

Lucent's Definity 
Nortel's Meridian 

The following are examples of central office (telephone 
company) switches, which perform circuit switching within 
the public telephone network: 

Lucent's ESS 

Nortel's DMS 

The following are examples of Digital Access Cross- 
connect Systems (DACS), which are configured to switch 
circuits among multiple ports. 
Tellabs' Titan products 
Lucent's DSX products 
Alcatel's SX products 
65 The following is an example of a PC-based PBX system: 
AltiGcn's AltiServ— PC-based PBX system for a small 
branch office or a low-volume specialized call center. 
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The following is an example of a circuit-switching/ 
packet-forwarding gateway: 

Lucent's Internet Telephony Server — server software that 
routes calls from PBXs over the Internet or intranets. 
Transporl Security 2410 

Transport Security services (within the Transport Services 
layer) perform encryption and filtering. 
Transport-layer Encryption 

Encryption within the Transport Services layer is per- 
formed by encrypting the packets generated by higher level 
services (e.g., Message Transport) and encapsulating Ibem 
in lower level packets (e.g., Packet Forwarding/ 
Internetworking). (Note that encryption can also occur 
within the Communications Services layer or the Network 
Media layer.) Encryption within the TVansport Services layer 15 
has the advantage of being independent of both the appli- 
cation and the transmission media, but it may make network 
monitoring and troubleshooting activities more difficult. 

The following standards support transport-layer encryp- 
tion: 

Point to Point Tunneling Protocol 
Layer 2 T\inneling Protocol 
Transport-layer Filtering 

Network traf&c can be controlled at the TYansport Services 
layer by filtering data packets based on source and/or 
destination addresses and network service. This ensures that 
only authorized data transfers can occur. This filtering is one 
of the roles of a packet filtering firewall. (A firewall is a 
system that enforces an access control pohcy between a 
trusted internal network and an untrustcd external network.) 

The following IETF standard supports interoperability 
among security systems: 

IPSec AHows two nodes to dynamically agree on a 
security association based on keys, encryption, authen- 
tication algorithms, and other parameters for the con- 
nection before any communications take place; oper- 
ates in the IP layer and supports TCP or UDP. IPSec 
will be included as part of IPng, or the next generation 
of IP. 

Implementation Considerations 

Firewalls can also provide a single point of access to the 
companys network, which could be used to maintain an 
audit traU. Some firewalls provide summaries to the admin- 
istrator about the type of trafiSc and amount of traf&c passed 
through it, number of break in attempts, etc. 

Most commercial firewalls are configured to reject all 
network traffic that has not been explicitly allowed, thus 
enforcing the policy. Only albw traffic that has been cat- 
egorically permitted, otherwise prohibit. This policy pro- 
vides much more control and is much safer than a policy 
which allows trafiBc unless it has been explicitly prohibited. 
Possible Product Options 

Cisco System;^ Bay Networks; 3Com Corp.; Check Points 
Firewall-1; Raptor Systems Eagle Firewall; Data Fellows 
F-Secure VPN; Racals Datacryptor 64F 
The following arc examples of vendors of products that 
perform Transport-level encryption: 
routers: 

Cisco Systems 

Bay Networks 

3Com Corp. 
firewalls: 

Check Point's Firewall- 1 

Secure Computing's BorderWare Firewall Server 
Raptor Systems' Eagle Firewall 
encryption devices: 



Data Fellows' F-Secure VPN 
Racal's Datacryptor 64F 
The following are examples of products that perform 
Transport-level packet filtering: 
firewalls: 

Check Point FireWall-1 — combines Internet, intranet 
and remote user access control with strong 
authentication, encryption and network address 
translation (NAT) services. The product is transpar- 
ent to network users and supports multiple protocols. 
Secure Computing's BorderWare Firewall Server pro- 
tects TCP/IP networks from unwanted external 
access as well as provides control of internal access 
to external services; supports packet filters and 
application-level proxies. 
Raptor Systems' Eagle Firewall 
routers: 
Cisco Systems 
Bay Networks 
3Com Corp. 
Network Address Allocation 2412 

Network Address Allocation sendees manage the distri- 
bution of addresses to network nodes. This provides more 
flexibility compared to having all nodes assigned static 
addresses. This service assigns addresses to nodes when they 
initially power-on and connect to the network. 

The following are examples of standards that implement 
Network Address Allocation and allow a network node to 
ask a central resource for the node_3 network address (e.g., 
IP address): 

DHCP (Dynamic Host Configuration Protocol) 
BootP (Bootstrap Protocol) 
Quality of Service 2414 

Different types of network traffic (e.g., data, voice, video) 
have different quality of service requirements. For example, 
data associated with video conferencing sessions is useless 
if it is not-delivered "on time". On the other hand, traditional 
best-cffoit data services, such as file or e-mail transfer, are 
not affected by variations in latency. QoS (Quality of 
^ Service) services deliver a defined network throughput for 
designated trafEic by allocating dedicated bandwidth, priori- 
tizing data traffic, etc. (Note that as an alternative to pre- 
defined throughput, some QoS protocols can also offer a best 
effort (i.e., variable) throughput QoS based on available 
network capacity.) 

The following list provides a description of various Qual- 
ity of Service parameters, 
connection establishment delay — time between the con- 
nection request and a confirm being received by the 
requester 

connection establishment failure probability — chance that 
the connection will not be established within the maxi- 
mum establishment delay 
throughput — bits per second (bps) of transmitted data 
transit delay — time elapsed between when sender trans- 
fers packet and recipient receives packet 
residual error rate — number of lost or corrupted messages 

compared to total messages in the sampling period 
transfer failure probability — the firaction of the time when 
the throughput, transit delay, or residual error were not 
those agreed upon at the start of the connection 
coimection release delay — time between when one node 
initiates a release and the other node performs the 
release 

coimection release failure probability — ^firaction of release 
attempts which do not succeed 
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protection — specifies a secure cormection 
priority — vindicates traffic priority over the connection 
resilience — probability thai the transport layer spontane- 
ously terminates 
QoS can be achieved in various ways as listed below: 
Specialized QoS Communications Protocols — provide 
guaranteed QoS. 

Asynchronous Transfer Mode (ATM) — ^ATM is a 
connection-oriented wide area and local area net- 
working protocol that delivers QoS on a per- 
connection basis. QoS is negotiated as part of the 
initial connection set up and as network conditions 
change. Because of the small size of ATM data cells, 
QoS can be better managed, compared to protocols 
such as Ethernet that have large frames that can tie 
up network components. For ATM to deliver QOS to 
applications, ATM must be used end-to-end. 

Resource Reservation Protocol (RSVP) — The emerg- 
ing RSVP specification, proposed by the Internet 
Engineering Task Force (lElT), allows applications 
to reserve router bandwidth for delay-sensitive IP 
traffic. With RSVP, QoS is negotiated for each appli- 
cation connection. RSVP enables the network to 
reserve resources from end to end, using Frame 
Relay techniques on Frame Relay networks, ATM 
techniques on ATM, and so on. In this way, RSVP 
can achieve QoS across a variety of network 
technologies, as long as all intermediate nodes are 
RSVP-capable. 
IP Stream Switching — ^improves network performance 

but does not guarantee QoS. 

IP Switching — IP Switching is an emerging technology 
that can increase network throughput for streams of 
data by combining IP routing software with ATM 
switching hardware. With IP Switching, an IP switch 
analyzes each stream of packets directed from a 
single source to a specific destination, and classifies 
it as short- or long-lived. Lx)ng-lived flows are 
assigned AIM JgjtualiOrannels ^VCs) that bypass 
the IP router and move through the switching fabric 
at the full ATM line speed. Short-lived flows con- 
tinue to be routed through traditional store-and- 
forward transfer. 

Tag Switching — Like IP Switching, emerging Tag 
Switching technology also improves network 
throughput for IP data streams. Tag Switching aggre- 
gates one or more data streams destined for the same 
location and assigns a single tag to all associated 
packets. This aUows routers to more efficicndy trans- 
fer the tagged data. Tag Switching is also known as 
Multiprotocol Label Switching. 
Data Prioritization — ^improves network performance but 

does not guarantee QoS. 

While not an example of end-to-end QoS, various 
network components can be configured to prioritize 
their handling of specified types of trafiBc. For 
example, routers can be configured to handle legacy 
mainframe traffic (SNA) in front of other traffic (e.g., 
TCP/IP). A similar technique is the use of prioritized 
circuits within Frame Relay, in which the Frame 
Relay network vendor assigns dififcrent priorities to 
different permanent virtual circuits. 

Prioritization techniques are of limited effectiveness if 
data must also pass through netwodc components 
that are not configured for prioritization (e.g., net- 
work components run by third party network 
providers). 
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Network Media Services 2416 

The Network Media layer provides the following capa- 
bilities: 

Final framing of data for interfacing with the physical 
network. 

Performing, receiving, interpreting and acting on signals 
from the commimications fabric. 

Transferring data through the physical network. 

The technologies used at the Network Media Services 
layer vary depending on the type of network under consid- 
eration. 

Media Access 2418 

Media Access services manage the low-level transfer of 
data between network nodes. Media Access services per- 
form the following functions: 

Physical Addressing — ^The Media Access service encap- 
sulates packets with physical address information used 
by the data link protocol (e.g., Ethernet, Frame Relay). 

Packet Transfer — ^The Media Access service uses the data 
link communications protocol to frame packets and 
transfer them to another computer on the same 
network/subnetwork. 

Shared Access — ^The Media Access service provides a 
method for multiple network nodes to share access to a 
physical network. Shared Access schemes include the 
foUowing: 

CSMA/CD— Carrier Sense Multiple Access with CoUi- 
sion Detection. A method by which multiple nodes can 
access a shared physical media by "listening" until no 
other transmissions are detected and then transmitting 
and checking to see if simultaneous transmission 
occurred. 

token passing — A method of managing access to a shared 
physical media by circulating a token (a special control 
message) among nodes to designate which node has the 
right to transmit 

multiplexing — ^A method of sharing physical media 
among nodes by consolidating multiple, independent 
channels into a single circuit. The independent chan- 
nels (assigned to nodes, applications, or voice calls) can 
be combined in the following ways: 
time division multiplexing (TDM) — use of a circuit is 
divided into a scries of time slots, and each inde- 
pendent channel is assigned its own periodic slot, 
frequency division multiplexing (FDM)— each inde- 
pendent channel is assigned its own frequency range, 
allowing all channels to be carried simultaneously. 

Flow Control — ^The Media Access service manages the 
flow of data to account for differing data transfer rates 
between devices. For example, flow control would have 
to limit outbound traffic if a receiving machine or 
intermediate node operates at a slower data rate, pos- 
sibly due to the use of different network technologies 
and topologies or due to excess network traffic at a 
node. 

Error Recovery — Ihe Media Access service performs 
error recovery, which is the capability to detect and 
possibly resolve data corruption that occurs during 
transmission. Error recovery involves the use of 
checksums, parity bits, etc. 

Encryption — The Media Access service may perform 
encryption. (Note that encryption can also occur within 
the Communications Services layer or the Transport 
Services layer.) Within the Network Media Sendees 
layer, encryption occurs as part of the data link protocol 
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(e.g. Ethernet, frame relay). In this case, all data is 
encrypted before it is placed on the wire. Sudi encryp- 
tion tools are generally hardware products. Encryption 
at this level has the advantage of being transparent to 
higher level services. However, because it is dependent 5 
on the data link protocol, it has the disadvantage of 
requiring a different solution for each data link proto- 
col. 

The following are examples of Media Access protocols: 

Ethernet 

token ring 

FDDI 

portions of the ATM standard 

HDLC/SDLC 15 
LAPB 

T-carrier, E-carrier (e.g., Tl, T3, El, E3) 
TDM and FDM (Time Division Multiplexing and Fre- 
quency Division Multiplexing; used on T-carriers, etc.) 
SONET, SDH 
PPP, SUP 

V.32, V34, V.34 bis, etc. 
RS-232, EIA-232 

25 

TDMA and FDMA(Time Division Multiple Access and 
Frequency Division Multiple Access; used on wireless 
links) 

Specialized services convert between addresses at the 
Media Access level (Le., physical addresses like Ethernet) ^ 
and the Packet Forwarding/bitemetworking level (i.e., net- 
work addresses like IP). The following protocols are 
examples of this functionality: 
ARP (Address Resolution Protocol) — allows a node to 
obtain the physical address for another node when only 35 
the IP address is known. 
RARP (Reverse Address Resolution Protocol) — allows a 
node to obtain the IP address for another node when 
only the physical address is known. 
Possible Product Options 40 
Semaphores Network Security System for Workgroups 
Semaphore's Network Security System for 
Workgroups — encrypts Ethernet. 
Physical Media 2420 

As illustrated in FIG. 25, the Physical Media is divided 45 
into two categories: 

1) , the physical connectors 2502 

2) , the physical media (wired or wireless) 2504 
Physical Connectors - 

The following are examples of wiring connectors used to 
connect network nodes to physical media: 
RJ-11, RJ-45 
BNC 

DB-9, DB-25 S5 

fiber optic connectors 
Physical Media 

Physical Media may be wired or wireless. Wired Physical 
Media includes wiring and cabling, while wireless Physical 
Media includes antennas, connectors, and the radio fre- 
quency spectrum. 

Tlie following are examples of wired physical media: 

twisted pair wiring, shielded twisted pair wiring 

coaxial cable 

fiber optic cable 

4-pair voice-grade wiring 
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The folloAving are examples of wireless physical media: 

ceEular antennas and the associated radio frequencies 

wireless local area network antennas and the associated 
radio frequencies 

sateUite-antennis'and the associated radio frequencies 
Transfeti6n012,1014 

A transaction is a unit of work that has the following 
(AGD) characteristics: 

A transaction is atomic; if interrupted by failure, all effects 
are imdone (rolled back). 

A transaction produces consistent results; the effects of a 
transaction preserve invariant properties. 

A transaction is isolated; its intermediate states are not 
visible to other transactions. Transactions appear to 
execute serially, even if they are performed concur- 
rently. 

A transaction is durable; the effects of a completed 
transaction are persistent; they are never lost (except in 
a catastrophic failure). 
A transaction can be terminated in one of two ways: the 
transaction is either committed or roUed back. When a 
transaction is committed, all changes made by the associated 
requests are made permanent. When a transaction is rolled 
back, aU changes made by the associated requests are 
undone. 

Transaction Services provide the transaction integrity 
mechanism for the application. This allows aU data activities 
within a single business event to be grouped as a single, 
logical unit of work. 

In small to moderate scale environments of less than 150 
simxiltaneous users on a single server, this service may be 
provided by the DBMS software with its re-start/recovery 
and integrity capabilities. 

For larger client/server environments distributed on-line 
transaction managers might be more applicable. These trans- 
action managers provide sharing of server processes across 
a large community of users and can be more efficient than 
the DBMSs. 

FIG. 26 illustrates several of the components of the 
Transaction areas of the Netcentric Architecture Framework, 
each of which will be discussed in more detail below. 
Transaction Monitor 2602 

The Transaction Monitor Services are the primary inter- 
face through which applications invoke Transaction Ser- 
vices and receive status and enor information. Transaction 
Monitor Services, in conjunction with Information Access 
and Communication Services provide for load balancing 
across processors or machines and location transparency for 
distributed transaction processing. 
Implementation Considerations 

Does the system access nonrelational data? 

Some TP monitors provide a method of accessing non- 
relational data, such as VSAM files or flat files, indepen- 
dently of where the file physically resides. If write access is 
required for these data sources, a TP monitor would provide 
more dependable messaging and two-phase commit capa- 
bilities than the data source messaging capabilities alone. 

Does the system require high throughput? 

Because TP monitors provide load balancing functionality 
and because they effectively reduce the number of connec- 
tions that must be made to the databases), they will help 
conserve the resources of the data servers and, as a result, 
increase the throughput of the system. Systems with high 
throughput requirements should consider using a TP moni- 
tor. 

Do the on-line applications need the support of interop- 
erability between autonomous, heterogeneous processors? 
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Some TP monitors are available on multiple platforms and 
maintain interoperability (communication, data translation, 
etc.) between heterogeneous resource managers (databases) 
and clients (UNIX, MS Windows NT, etc.)- For this reason, 
projects that intend to support a heterogeneous hardware 
environment should consider using a TP monitor. 

Is the system supposed to be highly available (i.e, 24x7), 
or mission critical? 

TP monitors offer robust functionality: two-phase 
commit, recovery/rollback, naming services, security 
services, can guarantee message delivery, can be maintained 
for high-availability operation and provides audit trail log- 
ging. Hierefore, the more mission critical the system, the 
more likely it is that a TP monitor should be used. 

Does the system require high availability? 

Because of their fault tolerance, TP monitors make a 
valuable addition to systems that require high availability. 
The automatic restart/recovery feature helps a system rec- 
ognize when components have failed and attempts to restart 
them. Also, because of the location transparency feature of 
service calling, if an entire node in a system goes down, 
clients may be able to reach the service they need on another 
node providing the same service. 

WiU the system be scaled in the future? 

TP monitors offer multiple scalability options. TP moni- 
tors can nm on machines ranging from PCs to mainframes. 
Monitors also scale by allowing new machines to be added 
dynamically to the system. Adding additional nodes in the 
production cycle is one TP monitor strength, although some 
monitors are better at doing this than others. If it is antici- 
pated that system volumes will increase during the system's 
Ufetime, scalability in itself is an excellent reason to use a TP 
monitor. 

Does the system have complex security requirements? 

All of the TP monitors available today provide security 
authorization/authentication services. Most of them utilize 
the Kerberos security package, developed at the Massachu- 
setts Institute of Technology (MIT}. 

Does the system access legacy systems? 

TP monitors can access databases and services running on 
mainframe systems. TP monitors frequently include main- 
frame networking capability and maintain transaction roll- 
back during mainframe accesses. If access to the legacy 
system is read only, the messaging capabilities of the data 
source will probably be sufficient. If access is write, 
however, the messaging and two-phase commit capabilities 
of the TP monitor would be more dependable. 

Is the system distributed across multiple nodes? 

TP monitors provide common administrative facilities to 
manage groups of servers. These facilities allow a system to 
be managed from one location with a common set of 
commands for each machine. 

How many users access the system concurrently? 

Different som^ces give different answers as to the number 
of concurrent users that necessitates the use of a TP monitor. 
The monitor vendors themselves give low values; the data- 
base vendors give high values. The middle groimd seems to 
be somewhere aroimd 250 users. This is by no means 
definitive, however; weigh each of the following questions 
when making the choice. 

Do the on-line applications accessAipdate more than one 
database or more than one type of database? 

The real strength of TP monitors is their ability to ensure 
a global two-phase commit over miiltiple, heterogeneous 
databases. A system that has this quality is a candidate for a 
TP monitor. 
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Is the system not a transaction processing system? 
Although TP monitors provide global two-phase commit 
"transaction processing" functionality, systems that do not 
need this feature can also benefit by using TP monitors. For 
5 example, the load-balancing feature in itself can help 
increase system performance. Also, the administrative facili- 
ties can help simplify system management. 
Is Data Dependent Routing Necessary? 
Data Dependent Routing is the ability to route requests to 
10 a particular server based upon the data passed within the 
request. TP monitors can provide this functionality, e.g. A 
system has several servers accepting requests from clients 
dispersed across North America. There are two groups of 
servers. One group of servers handles requests from all 
15 clients located in the USA while the other group serves 
requests from Canada. When a client sends a request to the 
system, a ffeld in the request message, defining the location 
of the client, is passed to the system. The TP monitor is then 
able to route the request to the conect group of servers (USA 
20 or Canada) based upon information in the request message. 
Is Reliable Queueing Necessary? 
TP monitors provide the abiKty to enqueue and dequeue 
requests to and from a reliable (stable storage) queue. Both 
the application and the administrator can control the order of 
25 the messages (service requests) in the queue. Messages can 
be ordered UFO, FIFO, time based, priority, or by some 
combination of these keys. 
Example 

A system updates a customer database. Suppose that the 

30 database has been partitioned such that the information on 
customers most likely to use a branch office is stored locally 
at a branch office. There is a requirement to maintain an 
up-to-date of the entire customer database at the home office. 
The application that updates the local customer master can 

35 place a copy of the update into a reliable queue. The queue 
can be forwarded to the home office via a WAN, and the 
updates can be replicated in the home office database. The 
queuing system can be used to assure that every update 
completed at the local office is completed at the home office. 

40 Is The System Multi-tiered? 

Transaction Services are typically used in three-tier and 
multi-tier architectures. Particularly in Netcentric 
environments, applications might need to support getting 
and providing access to multiple back-end services, across 

45 enterprises, as part of a single transaction or user aaivity. 
This can be especially challenging if the user does not own 
some or all of the back-end services and/or data that its 
application relies on. 
Product Considerations 

50 Is the client interested in stable or emerging technologies? 
TUXEDO has been in the TP marketplace for seven years 
and has the most installations of all TP monitors. Encina, 
TOP END, and CICS/6000 are relatively new and emerging. 
Does the client plan to use Windows NT? 

55 On Which platforms/operating systems do the servers 
run? 

TP monitor support for NT may be limited. 

Some TP monitors are capable of running on a wider 
variety of platforms/operating systems than others. 
60 Is the project installing a new system or rehosting/ 
dowiisizing an existing mainframe system? 

The UniKix, VIS/TP, and CICS/6000 monitors were 
developed specifically with rehosting in mind. TUXEDO, 
Encina, and TOP END are best suited to fresh installations. 
65 Does the system use PC-based clients? 

Each TP monitor offers different support for PC-based 
clients. TUXEDO and TOP END cunentiy provide DOS, 
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Windows, and OS/2 application programming interface 
(API) support. Endna offers PC support, but this feature is 
still in beta test. Several vendors have PowerBuilder and 
Visual Basic interfaces planned for their monitors, but as of 
this practice aid's printing, nothing has been released. 5 

On which platforms will client applications execute? 

New and re-engineered systems may be required to 
execute on a previously instaUed base of clients. 

Does the system require integration with other 3rd party 

'^'^^^ . . 10 

The client may expect the TP monitor to integrate with an 

already installed base of 3rd party development tools. 
Does the system require mainframe cormectivity? 
Of the foxu* monitors that arc evaluated in this practice aid, 
all of them offer varying levels of mainframe connectivity. 

Does the client have existing personnel with 
mainframes — QCS experience? 

CICS/6000 has a programming interface similar to main- 
frame CICS. The learning curve for mainframe CICS pro- 
grammers to Msc CICS/6000 would be minimal; for these 
same personnel to program using TUXED O, Encina, or TOP 20 
END, the learning curve would be substantial. On the other 
hand, because CICS/6000*s administrative facilities are not 
similar to mainframe CICS, administrative personnel will 
face a steep learning curve: they will need to learn UNIX, 
DCE, and Encina (the layers on which aCS/6000 is built). 25 
(NOTE: VIS/TP and UniKix are also implcmcnUtions of 
CICS in the UNIX environment, but they ere not included in 
this evaluation) 
Possible Product Options 

l\ixedo; CICS/6000; Encina; MS Transaction Server; 
Sybase Jaguar; TOP END; opcnUTM; TransTT Opeo/OLTP 
Below are commonly used transaction monitors: 
BEA TUXEDO — provides a robust middleware engine 
for developing and deploying business-critical client/ 
server applications. BEA TUXEDO handles not only ^5 
distributed transaction processing, but also application 
and the full complement of services necessary to build 
and run entecprise-wide applications. It enables devel- 
opers to create applications that span multiple hardware 
platforms, databases and operating systems. ^ 
IBMs CICS/6000 — an application server that provides 
industrial-strength, online transaction processing and 
transaction management for mission-critical applica- 
tions on both IBM and non-IBM platforms. CICS 
manages and coordinates all the different resources 45 
needed by applications, such as RDBMSs, files and 
message queues to ensure completeness and integrity of 
data. 

Transarcs Encina — implements the fundamental services 
for executing distributed transactions and managing 50 
recoverable data, and various Encina extended 
services, which expand upon the functionality of the 
toolkit to provide a comprehensive environment for 
developing and deploying distributed transaction pro- 
cessing. 55 

Microsofts Transaction Server (Viper) — a component- 
based transaction processing system for developing, 
deploying, and managing high performance, and scal- 
able enterprise, Internet, and intranet server applica- 
tions. Transaction Server defines an application pro- 60 
gramming model for developing distributed, 
component-based applications. It also provides a run- 
time infrastructure for deploying and managing these 
applications. 

Brief Product Considerations 65 
Encina — ^The Encina DTP (OLTP) was built on top of 
OSF's DCE. This is both its greatest asset and curse. 
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DCE offers a very complete set of functions including 
security services, RPC's, a directory service (like a 
yellow pages for clients to find services) and a standard 
time service, and it is truly cross-plafform and is 
endorsed by most vendors. The problem is that it is a 
resource hog, and is fairly slow. DCE is also somewhat 
immature in that there arc not many tools to help you 
administer or program applications (although many are 
on the way). Encina adds primarily a transactional 
element and some load balancing services to RPC's. It 
also provides an easier interface to work with (although 
it is still an administrative nightmare). 

The good news is that the tools are getting better all of the 
time. Also, Encina is very scalable and services can be 
on any machine in the network. Finally, Encina's load 
balancing is quite good, much better then native DCE 
or 'I\jxedo. 

TUxedo 

Fxmctionality 

Can handle a large number of concurrent cUent applica- 
tions 

Can handle a large volume of through-put (ex. 1000+TPS) 
Scaleable (handle many clients or a few without code 
rewrite) 

Supports Transactions, including XA transactions 

Has its own transaction resource manager 

Guaranteed message delivery using a stable storage queue 

m 

Future service delivery using /Q (usually for batch 
processing) 

Can prioritize messages — most important get processed 
sooner. 

Supports many platforms (all UNIX, NT, all common 

client platforms) 
Ibxedo supports C, C++, and Cobol development 
Can be used for basic c/s messaging 
Supports conversational messaging between a client and 

a specific server 
Peer-to-peer, client-to-clieot messaging is supported 
Unsolicited messaging is supported for client processes 
Asynchronous service calls can be made by client and 

server processes 
Synchronous service calls can be made by client and 

server processes 
Synchronous calls that receive no return message are 

supported 

Very good security — must connect to access services 

Security can be integrated w/Kerberos 

Has many different buffer types: view to pass C structs, 

FML to pass anything, carrays to pass binary (sound, 

video), strings to pass strings 
FML allows dynamic messages to be sent/received 
Automatic error logging for Tuxedo components (ULOG, 

tagent log) 

Application code can write to the ULOG with a Tuxedo 

API (error logging provided) 
Automatic process monitor for process that die or 

machines that get partitioned 
Service location independency (distribution/directory 

services) 

Platform independency — handles data conversion 
Built in data compression (if desired) 
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Biiilt in performance measurement feature for services 
Built in admin functions to monitor Tuxedo system online 
(tmadmin) 

A server can be called based on data in the message (Data 

Depeadent Routing) 
Customizable server start-up and shutdown functions arc 

automatically called. 
/Domains allow independent Tbxedo regions to share 

services 

Extensions to execute IMS and QCS transactions finom 

UNIX (Open Transport) 
Subscribe and Broadcast supported 
APIs to get admin and system monitoring data for custom 

operation tools 
JOLT (java to access Tuxedo servers) 
Other Reasons to Use I\ixedo 
Tuxedo is the market leader OLTP 
'Rixedo is a proven product used in mission critical 

systems govt, and finaocial) 
Tuxedo can be used to develop highly-available systems 

(24x7) 

Has been implemented with PowerBuilder, VisualBasic, 

Motif clients, and unix batch systems. 
Cons of Using Ibxedo 
T^ixedo for basic c/s messaging is overkill. 
Expensive to purchase 

Can be complicated to develop with and administer 
System performance tuning requires an experienced TXix- 

edo administrator 
Uses IPC resources and therefore should not be on same 

machine w/other IPC products 
Must be understood thoroughly before design starts. If 

used incorrectly, can be very costly. 
Single threaded servers requires an upfront packaging 

design. 
Difficult to debug servers 

Does not work well with Pure Software products: Purify, 
Quantify 

Servers must be programmed to support client context 
data management 

Difficult to do asynch messaging in 3rd party Windows 
3.x client tools (ex. PowerBuilder) 
Resource Management 2604 

A Resource Manager provides for concurrency control 
and integrity for a singular data resource (e.g., a data base or 
a file system). Integrity is guaranteed by ensuring that an 
update is completed correctly and entirely or not at all. 
Resource Management Services use locking, commit, and 
rollback services, and are integrated with Transaction Man- 
agement Services. 
Transaction Management 2606 

Transaction Management Services coordinate transac- 
tions across one or more resource managers either on a 
single machine or multiple machines within the network. 
Transaction Management Sendees ensure that all resources 
for a transaction are updated, or in the case of an update 
failure on any one resource, all updates are rolled back. 

Hiis services that allow multiple applications to share 
data with integrity. The transaction management services 
help implement the notion of a transaction — a set of com- 
putations producing changes to recoverable data which 
demonstrate the ACID properties: 
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Atomicity — all changes arc made completely 
(committed) or not at all (roU-back). 

Consistency — the effects of a transaction preserve invari- 
ant properties. 

^ Isolation — intermediate data values are not visible to 
other transactions. 
Durability — the efEect of a completed transaction are 
persistent. 

TWo-Phase Commit is a feature found in distributed 
database management systems and online transaction pro- 
cessing (OLTP) monitors to ensure information integrity 
across distributed databases. With this feature, a transaction 
is only commited if two databases have the necessary 

J J information. If a problem arises on a network connection or 
a computer, the software will roll the transaction back so it 
will not be entered in either place. A restart mechanism may 
then retdy to complete the transaction. 
Possible Product Options 

20 Tuxedo; Encina; TOP END; CICS/6000; openUTM; Tran- 
sIT Open/OLTP 
Transaction Partitioning 2608 

Transaction Partitioning Services provide support for 
mapping a single logical transaction in an application into 

25 the required multiple physical transactions. For example, in 
a package or legacy rich environment, the single logical 
transaction of changing a customer address may require the 
partitioning and coordination of several physical transac- 
tions to multiple application systems or databases. Transac- 

30 tion Partitioning Services provide the application with a 
simple single transaction view. 
Implementation Considerations 

Must the system support logical transactions that occur 
across heterogenous application servers and databases? 

35 Example 

In a given application, a single business process of 
updating a customer record reqmres an update to a table 
in a UNIX based relational database and then an update 
to a table in a MVS DB2 database. Although there are 
^ two physical transactions occurring, this entire business 
process is represented as a single logical transaction. 
Transaction Partitioning services allow the application 
to ensure that the individual transactions occurr across 
the different UNIX and MVS systems and that the 
45 single logical transaction is completed and successful 
when the individual physical transactions are com- 
pleted and successful. 
Environment 1016,1018 

FIG. 27 illustrates various components of the Environ- 
mental Services of the Netcentric Architecture Framework. 
Environment Services provide miscellaneous application 
and system level services that do not deal directly with 
managing the user-interface, communicating to other 
programs, or accessing data. 
Runtime Services 2702 

Rxmtime services convert non-compiled computer lan- 
guages into machine code during the execution of a pro- 
gram. 

Language Interpreter 2704 

Language Interpreter Services decompose a 4tb genera- 
tion and/or a scripting languages into machine code 
(executable code) at runtime. 
Possible Product Options 
g5 VBRUN300.DLL 

VBRUNSOO.DU^-runtime Dynamic Link Library that 
supports programs written in Visual Basic. 
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Virtual Machine 2706 

Typically, a Mrtual Machine is implemented in software 
on top of an operating system^ and is used to run applica- 
tions. The Virtual Machine provides a layer of abstraction 
between the applications and the underlying operating sys- 
tem and is often used to support operating system indepen- 
dence. 

Possible Product Options 

Java virtual machine; Smalltalk virtual machine 

\^rtual machines such as the Java virtual machine or the 

Smalltalk virtual machine implement their own versions of 

operating system services in order to provide the application 

with complete platform independence. 

Java virtual machine — software implementation of a 
"CPU" designed to run compiled Java byte code. This 
includes stand-alone Java applications as well as 
"applets" that are downloaded and run in Web brows- 
ers. 

Smalltalk virtual machine — runtime engine that interprets 
application code during execution and supports plat- 
form independence. 
System Services 2708 

Services which applications can use to perform system- 
level functions. These services include: System Security 
Services, Profile Management Services, Task and Memory 
Management Services, and Environment Verification Ser- 
vices. 

System Security 2710 

System Security Services allow applications to interact 
with the operating system's native security mechanism. The 
basic services include the ability to login, logoff, authenti- 
cate to the operating system, and enforce access control to 
system resources and executables. 
Profile Management 2712 

Profile Management Services are used to access and 
update local or remote system, user, or application profiles. 
User profiles, for example, can be used to store a variety of 
information such as the user's language and color prefer- 
ences to basic job function information which may be used 
by Integrated Performance Support or Workflow Services. 
Implementation Considerations 

Is there a need for the application to have its own profile 
file? 

All MS Windows based application maintain their own 
profile file (XXXXXXXX.IN1) that is used during applica- 
tion startup, execution, and shutdown. This is a flat text file 
that contains information that can be vsed by the application 
during various phases of execution. For example, if an 
application needs to connect to a database engine/server, it 
needs to know, during startup, various information like — 
database name, the server name, login ID, etc. Instead of 
hard coding all these information in the application 
executable, this information can be stored in the profile file 
for flexibility. In the future, if the database server name 
should change, this change only needs to be entered in the 
applications profile file. In some cases, it has been seen that 
this profile information has been hard coded in that appli- 
cations executable itself. This will work, but, it makes the 
application more rigid with no room for any flexibility. 
Environment Veriflcation 2714 

Environment Verification Services ensure functionality by 
monitoring, identifying and validating environment integrity 
prior and during program execution, (e.g., free disk space, 
monitor resolution, correct version). These services are 
invoked when an apphcation begins processing or when a 
component is called Applications can use these services to 
verify that the correct versions of reqxiired Execution Archi- 
tecture components and other apphcation components are 
avaflable. 
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Implementation Considerations 

In client/server applications, it may be necessary to imple- 
ment Environment Verification Services to ensure that the 
client and server applications are of a compatible release 
5 level. 

ActiveX framework provides services for automatic 
installation and upgrade of ActiveX controls. When using 
IE, i.e., Microsoft's Web browser, because of its integration 
with Windows OS, ActiveX controls can be automatically 
installed and automaticaUy upgraded on the users machine 
without the developer adding any additional code. 
Task and Memory Management 2716 

Task & Memory Management Services allow applications 
and/or other events to control individual computer tasks or 
j5 processes, and manage memory. They provide services for 
scheduling, starting, stopping, and restarting both client and 
server tasks (e.g., software agents). 
Implementation Considerations 

Memory management, the aUocating and freeing of sys- 
20 tem resources, is one of the more error prone development 
activities when using 3GL development tools. Creating 
architecture services for memory handling functions can 
reduce these hard to debug errors. 
Java removes, in theory, the problem of memory 
25 management, by providing a garbage collector; although, its 
implementation is not very efficient in current implementa- 
tions of Java. Future releases of the Java VM promise a 
background-ruiming garbage collector with significantly 
increased performance. 
3Q Application Services 2718 

Application Services are miscellaneous services which 
applications can use for common functions. These common 
fiinctions can apply to one application or can be used across 
applications. They include: Apphcation Security Services, 
35 Error Handling/Logging Services, State Management 
Services, Help Services, and Other Common Sen^ices. 
Application Security 2720 

Besides system level security such as logging into the 
network, there are additional security services associated 
with specific applications. These include: 
User Access Services — set of common functions that limit 
application access to specific users within a company or 
external customers. 
Data Access Services — set of common functions that limit 
45 access to specific data within an application to specific 
users or user types (e.g., secretary, manager). 
Function Access Services — set of common functions that 
limit access to specific functions within an application 
to specific users or user types (e.g., secretary, manager). 
50 Implementation Considerations 

In the Netcentric environment, application security 
becomes a more critical component primarily because there 
are more types of users (e.g., employees, customers) and 
additional types of transactions (e.g., e-commerce, help- 
55 desks). In traditional client/server environments most users 
are employees of the company. In Netcentric environments 
there are typically also external users (e.g., vendors, regis- 
tered users) and the general public. Usually, different types 
of users have different application security requirements 
60 hmiting what data they can see and what functions diey can 
execute. Also, new types of transactions such as verifying 
credit when doing e-commerce transactions also require 
additional application security services. 
Error Handling/Logging 2722 
65 Error Handling Services support the handling of fatal and 
non-fatal hardware and software errors for an application. 
An error handling architecture takes care of presenting the 
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user with an understandable explanation of what has hap- Management Services (storing state information on the 
pened and coordinating with other services to ensure that server). The HTTP protocol is a stateless protocol Every 
transactions and data are restored to a consistent state. connection is negotiated firom scratch, not just at the page 
Logging Services support the logging of informational, level but for every element on the page. The server does not 
error, and warning messages. Logging Services record appli- 5 maintain a session connection with the client nor save any 
cation and user activities in enough detail to satisfy any audit information between client exchanges (ie., web page sub- 
trail requirements or to assist the systems support team in mils or requests). Each HTTP exchange is a completely 
recreating the sequence of events that led to an error. independent event. Therefore, information entered into one 
Implementation Considerations HTML form must be saved by the associated server appli- 
Error Handling -^q cation somewhere where it can be accessed by subsequent 

Primarily there are three types of errors: system, archi- programs in a conversation, 
tecture and application. Advances in Netcentric technologies now offer additional 
System errors occur when the application is being options for implementing state management on both the 
executed and some kind of serious system-level incom- client and server machines, 
patibility is encountered, such as memory/resource ^5 Possible Product Options 
depletion, database access problems, network problems NetDynamics Inc. NetDynamics 
or printer related problems, because of which the NetDynamics Inc. NetDynamics 
application cannot proceed with its normal execution. NetDynamics provides built-in, developer-definable scs- 
Architecture errors are those which occur during the sion and state management. The Persistence Engine 
normal execution of the application and are generated 20 (PE), part of the NetDynamics application server, 
in ardiilecture functions that are built by a project stores all relevant information about a user. Everything 
architecture team to isolate the developers from com- from the WebID to the exact table row the user is 
plex coding, to streamline the development effort by currently viewing can be maintained in the PE. Net- 
re-using common services, etc. These architecture Dynamics maintains state information on both the 
functions perform services such as database calls, slate 25 server and on the client page. Application state infor- 
management, etc. mation is maintained by the application server, and 
Application errors are also those which occur during the local state information is maintained on the page, 
normal execution of the application and are generally NetDynamics provides manipulatable state objects for 
related to business logic errors such as invalid date, both server and page state information, 
invalid price, etc. 30 Codes Table Service 2726 
Typically an application is written using a combination of Codes Table Services enable applications to utilize exter- 
various programming languages (e.g., Msual Basic and C). nally stored parameters and validation rules. For example, 
Therefore, a common error handling routine should be an application may be designed to retrieve the tax rate for the 
written in a language that can be called from any other State of Illinois. When the user enters "Illinois" on the 
language used in the application. 35 screen, the application first validates the user's entry by 
Logging checking for its existence on the "State Tax Table", and then 
Logging must be done, however to mitigate problems, retrieves the tax rate for Illinois. Note that codes tables 
centralize logs and create a standard, usable log format. 3rd provide an additional degree of flexibility. If the tax rates 
party logs should be mapped into the central format before changes, the data simply needs to be updated; no application 
any analysis is attempted. 40 logic needs to be modified. 

In a Netcentric environment, errors are rarely logged on Implementation Considerations 

the client machine (one exception may be for an intranet Is there a need for the codes table functionality? 

type application). Most applications need code/decode facility. For 

Logging can add much stress to a Web server and logs can example, an application may need to store codes like — error 

grow very large, very quickly, so do not plan to log all 45 severity codes, etc., stored in a table (may be a cached table) 

errors — capture only those which are deemed necessary for instead of in the executable itself. In some cases, where there 

processing exceptions. is a small amount of information that needs to be stored in 

State Management 2724 the codes table, the profile file (mentioned above) can be 

State Management Services enable information to be usedinsteadof the codes table. But in cases where the codes 

passed or shared among windows and/or Web pages and/or so table needs to be used quite extensively, then storing the 

across programs. So lets say several fields in an application code/decode information in the profile file will slow down 

need to be passed from one window to another. In pseudo- the performance of the application because of the overhead 

conversational mainframe 3270 style applications passing of accessing flat files. 

data firom one* screen to another screen was done using What basic services an architecture should provide in 

Context Management Services that provided the ability to 5S terms of managingAising codes/decodes functionality? 

store information on a host computer (in this paper the term In cases where the application requires extensive use of 

Context Management refers to storing state information on codes table, the architectures Code/Decode component 

the server, not the client). Client/server architectures sim- should provide the application developers with a set of API 

plified or eliminated the need for Context Management that can be used to tise code/decode tables. This component 

(storing state information on the server), and created a need 60 should also provide the option of caching all or parts of the 

to store state information on the client. Typically, in tradi- codes table in the application machines memory for easier 

tional client/server systems this type of state management and faster access. 

(i.e., data sharing) is done on the client machine using Where should Code/Decode information be stored and 

hidden fields, global variables, messages, files or local maintained? 

databases. 65 Code/decode information can be stored at any layer of an 

The popularity of the Intcmets Hl'l'P protocol has revived n-tier architecture — client, application server, or database, 

the potential need for implementing some form of Context The decision wiU need to be based upon codes table size and 
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number, information update frequency, and write -access to 
the client machine or device. 
Active Help 2728 

Active Help Services enable an application to provide 
assistance to a user for a specific task or set of tasks. 
Context-sensitive help is most commonly used in applica- 
tions today, however this can imply more "active'* support 
that just the Fl key. Typically, today's systems must be 
architected to include Help that is aware of both the user's 
environment, process and context, and in this sense can be 
called "active". Active Help services may include compo- 
nents like Wizards for walking a user through a new process, 
stored or real-time multi-media support, on-demand Com- 
puter Based Training, etc. 
Other Common Services 2726 

Catchall category for additional reusable routines useful 
across a set of applications (e.g.. Date Routines, Time Zone 
Conversions, Field Validation Routines). 
Implementation Considerations 

Does the client operate in different date/time zone? 

In most large scale distributed applications, the client and 
the server appKcations (or machines) arc scattered over 
different time zones. This forces the client applications and 
the server hosts to deal with date and time zone conversions 
(like — CST to PST, etc.) in order to use or display their local 
time accurately. Most of the architectures provide a base set 
of APIs that can be used by the applications to convert the 
data/time as needed. 

Does the system requires customized date/time format for 
display purposes? 

Many systems, for certain business reasons, need custom- 
ized date and time formats for display and storage purposes. 
In order to do that, the architecture should provide a set of 
APIs that will allow the system to convert data and time 
from one format to the other. 

Does the system deal with high database accesses? 

As mentioned in the Codes Table Component, sometimes 
it is necessary to cache the data in the memory for faster 
access and less database hits. This a feature that some 
architectures provide as a set of memory management APIs 
to create the cache area in the chent platforms memory for 
the data to reside. 

AppUcation Integration Interface 2734 

An Application Integration Interface provides a method or 
gateway for passing context and control of information to an 45 
external application. The Application Integration Interface 
specifies how information will be passed and defines the 
interface by which other appUcations can expect to receive 
information. External applications in this context could 
include anything from Integration Performance Support 50 
systems to ERP systems like SAP or Peoplesoft to external 
custom applications that have been previously developed by 
the client. 

Implementation Considerations 

Where pckssible, AppUcation Integration Interfaces should 
make use of the Component Model defined by the project to 
broker information (i.e, OLE/COM interfaces) as opposed to 
custom building data sharing modules. 
Component Framework 2736 

Component Framework Services provide an infrastruc- 
ture for building components so that they can commxmicate 
within an application and across applications, on the same 
machine or on multiple machines across a network, to work 
together. COM/DCOM and CORBA described in Commu- 
nication Services are the two leading component industry 
standards. These standards define how components should 
be built and bow they should communicate. 
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Object Request Broker (ORB) services, based on COM/ 
DCOM and CORBA, focus on how components communi- 
cate. Component Framework Services, also based on 
CORBA and COM/DCOM, focus on how components 
should be built. The currently 2 dominant Component 
Frameworks include: 

1. ActiveX/OLE — ^ActiveX and Object Linking and 
Embedding (OLE) are implementations of COM/ 
DCOM. ActiveX is a collection of facilities forming a 
framework for components to work together and inter- 
act. ActiveX divides the world into two kinds of 
components: controls and containers. Controls are rela- 
tively independent components that present well 
defined interfaces or methods that containers and other 
components can call. Containers implement the part of 
the ActiveX protocol that allows for them to host and 
interact with components — ^forming a kind of back 
plane for controls to be plugged into. ActiveX is a 
scaled-down version of OLE for the Internet OLE 
provides a framework to build applications from com- 
ponent modules and defines the way in which apphca- 
lions interact using data transfer, drag-and-drop and 
scripting. OLE is a set of common services that allow 
components to collaborate intelUgently. 

In creating ActiveX from OLE 2.0, Microsoft enhanced 
the framework to address some of the special needs of 
Web style computing. Microsofts Web browser, Inter- 
net Explorer, is an ActiveX container. Therefore, any 
ActiveX control can be downloaded to, and plugged 
into the browser. This allows for executable compo- 
nents to be interleaved with HTML content and down- 
loaded as needed by the Web browser. 

2. JavaBeans — ^is Sun Microsystems proposed framework 
for building Java components and containers. The 
intent is to develop an API standard that will afiow 
components developed in Java (or beans), to be embed- 
ded in competing container frameworks including 
ActiveX or OpenDoc. The JavaBeans API will make it 
easier to create reusable components in the Java lan- 
guage. 

Other component frameworks include: 

OpenDoc — CI Labs was formed in 1993 and created the 
OpenDoc architecture to provide a cross-platform alter- 
native component framework — independent of 
Microsofts OLE. The OpenDoc architecture is con- 
structed from various technologies supplied by its 
founding members — ^IBM, Apple and Word Perfect. 
The technologies include: Bento (Apples object storage 
model), Open Scripting Architecture (OSA— Apples 
scripting architecmre) and SOM/DSOM (IBMs System 
Object Model/Distributed SOM). IBMs SOM architec- 
ture provides analogous services to that of Microsofts 
DCOM architecture. 

OpenDoc provides an open compound document infra- 
structure based on CORBA It uses CORBA as its 
object model for inter-component communications. 
OpenDoc architecture provides services analogous to 
those provided by OLE and OpenDoc components can 
also inter-operate with OLE components. The Open- 
Doc equivalent of an object is termed a part. Each type 
of part has its own editor and the OpenDoc architecture 
has responsibihty for handling the conmiunications 
between the distinct parts. 

Supporters claim OpenDoc provides a simpler, more 
technically elegant solution for creating and manipu- 
lating components than does OLE. The drawback is 



06/17/2004, EAST Version: 1.4.1 



us 6,636, 

105 

that OpenDoc is not yet commercially proven, like 
OLE. Ironically, one of the more popular uses of 
OpenDoc tools is for creating and implementing OLE 
clients and servers. Because OpenDoc provides a more 
manageable set of APIs than OLE, it may be that 5 
OpenDoc gains initial acceptance as an enabler of OLE 
applications before becoming recognized as a complete 
component software solution itself. 
ONE — Open Network Environment (ONE) is an object- 
oriented software framework from Netscape Commu- 
nications for use with Internet clients and servers, 
which enables the integrating of Web clients and serv- 
ers with other enterprise resources and data. By sup- 
porting CORBA, ONE-enabled systems will be able to 
link with object software from a wide array of vendors, 
including IBM, Sun Microsystems, Digital Equipment, 
and Hewlett-Packard, Netscape is positioning ONE as 
an alternative to Microsoft's Distributed Common 
Object Model (DCOM). ONE also complies with Sun 
Microsystems Java technology. 
Implementation Considerations 20 

An architecture thai utilizes components brings many of 
the benefits of object orientation to applications. 
Component-based or document-centric applications are 
composed of intelligent components, each of which contains 
logic, possibly data and a set of well defined interfaces or 25 
APIs to the services ihey provide (e.g., a customer compo- 
nent or an Excel chart component). The similarities to object 
oriented are more than just coincidental. Component soft- 
ware is viewed by many as a more viable object approach 
focusing on larger grain of modularity and reuse. 30 

1\vo important issues driving the decision around what 
should be a component are software re-use and software 
packaging. Software re-use will primarily stem from defin- 
ing components at a level at which they can be re-used 
within the same application and across many applications. 35 
Although re-usable components can be at any level, more 
often they will probably be at an object level where they are 
more granular. Software packaging will be driven by defin- 
ing components at a level at which they can be distributed 
efficiently to all users when business logic changes occur. If 40 
the application is large, perhaps it is better to package the 
application by breaking it up into process components such 
as customer maintenance, sales order maintenance, etc. So 
when a change to one of the processes occurs, only the 
component which contains that process needs to be distrib- 45 
uted to client machines, rather than the whole application. 
For example, a developer can create an ActiveX control that 
will encapsulate the Employee Maintenance Process, which 
includes adding new employees, updating and deleting 
existing employees. This ActiveX control can be a part of an 50 
overall human resource intranet application. When the func- 
tionality within the Employee Maintenance Process 
changes, the next time the user accesses the human resource 
application from the Web browser, ActiveX technology will 
automatically download the latest version of the ActiveX ss 
control containing the most recent update of the Employee 
Maintenance Process to the cUent machine, if the client 
machine docs not have the latest version. 

Component architectures typically employ of a three-tier 
component architecture utilizing the following three types of go 
components: 

User Interface, Process, and Domain. While these three 
component types may go by different names on different 
projects, they all follow the same basic pattern and are 
briefly explained below: 65 

User Interface components typically contain nothing 
more than the logic required to manipulate input and 
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output to the user. This can include input validation 
requiring no additional server data, as well as simple 
calculations associated with field display In addition, 
logic associated with dynamically changing the display 
(e.g., a checkbox entry causes a field to become 
disabled) is placed here. 
Process components typically contain the logic associated 
with bxisiness transactions performed on data. This is 
often the point where transaction commit/rollback 
occurs. These components are typically invoked by the 
User Interface components. 
Domain components typically contain the logic associ- 
ated with accessing and maintaining business entities, 
Le., data. These components are \isually invoked by 
Process components when requiring access to or 
manipulation of data. However, in addition to data 
access, these components may often be used to perform 
manipulations involving the processing of data within 
the domain of that component. For example, a Cus- 
tomer Domain component might be requested to deter- 
mine if it's credit limit had been exceeded when 
provided with a new invoice amount. 
Build vs. Buy 

There is an explosion of components available in the 
market place and the ease of accessing and down loading 
components from the Internet; the decision to buy or build 
a component is as real as ever. In general clients expect more 
justification of a build decision v. a buy decision. Feel out 
the client and the expectations and requirements they may 
have. 

Components are a viable option and should be researched, 
even including even simple UI controls available on the 
Internet. Look at market trends to determine which 
applications/components can meet the bulk of the system 
needs. 

Operating System 2738 

Operating System Services are the underlying services 
such as multi-tasking, paging, memory allocation, etc., 
typically provided by today's modem operating systems. 
Wiere necessary, an additional layer or APIs may be pro- 
vided to gain either operating system independence or a 
higher level of abstraction for application programmers. 
Possible Product Options 

Microsoft Windows; Windows 95; Windows NT; Macintosh 

OS; OS/2; Unix and Java OS 
Base Services 1020 
Component Description 

FIG. 28 illustrates the Base Services of the Netcentric 
Architecture Framework. Base Services provide server- 
based support for delivering applications to a wide variety of 
users over the Internet, intranet, and extranet. The informa- 
tion about these services in the Netcentric framework may 
be limited based on the least common denominator. For 
more detailed information about these components refer also 
to the following frameworks in SAF and/or DAF. 
Batch Delivery Vehicle 

Collaboration Framework for Structuired Information 
(Workflow) 
Web Services (2820) 

Web Server Services enable organizations to manage and 
publish information and deploy Netcentric applications over 
the Internet and intranet environments. These services sup- 
port the following: 
Managing documents in most formats such as HTML, 

Microsoft Word, etc. 
Handling of client requests for HTML pages. A Web 
browser initiates an HTTP request to the Web server 
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either specifying the HTML document to send back to 
the browser or the server program (e.g., CGI, ASP) to 
execute. If the server program is specified, the Web 
server executes the program which generally returns a 
formatted HTML page to the Web Server. The Web 
server then passes this HTML page just as it would any 
standard HTML document bade to the Web browser. 
Processing scripts such as Common Gateway Interface 
(CGI), Active Server Pages (ASP). Server side script- 
ing enables programs or conamands to be executed on 
the server machine providing access to resources stored 
both inside and outside of the Web server environment. 
For example, server side scripts can be used to process 
requests for additional information, such as data from 
an RDBMS. 

Caching Web pages. The first time a user requests a Web 
page, the Web server retrieves that page from the 
network and stores it temporarily in a cache (memory 
on the Web server). When another page or the same 
page is requested, the Web server first checks to see if 
the page is available in the cache. If the page is 
available, then the Web server retrieves it from the 
cache, otherwise it retrieves it from the network. 
Qearly, the Web server can retrieve the page from the 
cache more quickly than retrieving the page again from 
its location out on the network. The Web server typi- 
cally provides an option to verify whether the page has 
been updated since the time it was placed in the cache, 
and if it has to get the latest update. 
Possible Product Options 

Netscape Enterprise Web Server; Microsoft Internet Infor- 
mation Server (IIS); Oracle Webserver 
Hie following are relevant products for providing or 
implementing HTTP Web Server Services: 
Netscape Enterprise Web Server 
An enterprise-strength Web server that enables organiza- 
tions to manage and publish their information and 
deploy Netcentric applications. Netscape Enterprise 
Web Server is built on open Intemet standards that 
enable information and applications to scale easily. 
Supports S-HTTP, Java, and SNMR 
Microsoft Intemet Information Server (IIS) 
A free add-on product for NT Server that implements 
basic HTTP services. Future versions of NT Server (4.0 
and beyond) wiU have HTTP features built directly into 
the operating system. 
Oracle Webserver 

A multi-threaded HTTP server that provides integrated 
features for translating and dispatching client HTTP 
requests direcdy to the Oracle? Server using PL/SQL. 
Push Pull Services (2840) 

Push/Pull Services allow for interest in a particular piece 
of information to be registered and then changes or new 
information to be communicated to the subscriber list. 
Traditional Internet users "surf' the Web by actively moving 
from one Web page to another, manudly seardiing for 
content they want and "pulling" it back to the desktop via a 
graphical browser. But in the push model, on which sub- 
scription servers are based on, content providers can broad- 
cast their iuformation directly to individual users* desktops. 
The technology uses the Internet's strengths as a two-way 
conduit by allowing people to specify the type of content 
they want to receive. Content providers then seek to package 
the requested information for automatic distribution to the 
user's PC. 

Depending upon requirements, synchronous or asynchro- 
nous push/pull services may be required. Synchronous push/ 
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pull services provide a mechanism for applications to be 
notified in real time if a subscribed item changes (e.g., a 
stock ticker). Asynchronous push/pull services do not 
reqiure that a session-like connection be present between the 
5 subscriber and the information. Internet ListServers are a 
simple example. Subscribers use e-mail to register an inter- 
est in a topic and are notified via e-mail when changes occur 
or relevant information is available. Asyndironous push/pull 
services can be useful for pro-actively updating customers 
10 on changes in order status or delivering information on new 
products or services they have expressed an interest in. 
PointCast; Marimba; IBM/Lotus; Microsoft; Netscape; 
America Online; BackWeb; Wayfarer 
Castanet from Marimba — distributes and maintains soft- 
15 ware applications and content within an organization or 
across the Internet, ensuring subscribers always have 
the most up-to-date information automatically. 
PointCast — news network that appears instantly on the 
subscribers computer screen. 
^ Batch Services (B2060) 

Batch processing is used to perform large scale repetitive 
processing where no user involvement is required as well as 
reporting. Areas for design attention include scheduling, 
recovery/restart, use of job streams and high availability 
^ (e.g. 24 hour nmning). In addition close attention must be 
paid to performance as batch systems usually must be 
processed within strict batch windows. 

Hie design of batch architectures is often complicated 
considerably by the fact that batch jobs must be able to run 
^ concurrently with on-line systems. The general globalization 
of companies requires that he on-line systems must be 
available on a close to 24x7 hours basis, eliminating the 
traditional batch windows. Concurrent batch and on-line 
processing poses serious challenges to data integrity, 
throughput and performance. 

Batch application programs can include business process- 
ing such payroll, billing, etc. and can also include report 
generation. This is an often overlooked area in client/server 
architectures. Traditional clienV^server solutions and Netcen- 
^ trie solutions often require batch processing, but unlike the 
mainframe, the typical platforms and development environ- 
ments used often do not have built-in batch or reporting 
architecture facilities. 

Batch processing should be used in preference to on-line 
modules when: 

The same process, or set of processes, must be applied to 
many data entities in a repetitive and predictable fash- 
ion. 

50 There is either no manual element to the process or the 
manual element can be completely separated from a 
batch element. 
The volume of information to be presented to a user is too 
great to be processed on-line or it can be better printed 
55 in batch. 
Related Patterns 

For more detailed information about component based 
batch design patterns, refer also to the Batch patterns in the 
Patterns section: 
60 Base Services Patterns Overview 
Abstraction Factory 
Batch Job 

BUW— Batch Unit of Work 
Processing Pipeline 
65 Report Services (2880) 

Report Services arc facilities for simplifying the construc- 
tion and delivery of reports or generated correspondence. 
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These services help to define reports and to electronically 
route reports to allow for online review, printing, and/or 
archiving. Report Services also support the merging of 
application data with pre-defined templates to create letters 
or other printed correspondence. Report Services include: 5 
Driver Services. These services provide the control struc- 
ture and ficamework for the reporting system. 
Report Definition Services. These services receive and 
identify the report request, perform required validation 
routines, and format the outputted report(s). After the 
request is validated, the report build function is initi- 
ated. 

Report Build Services. These services are responsible for 
collecting, processing, formatting, and writing report 
information (for example, data, graphics, text). 

Report Distribution Services. These services are respon- 
sible for printing, or otherwise distributing, the reports 
to users. 

Functions and Features of a Report Architecture 20 

The report architecture within Environment Services sup- 
ports the generation and delivery of reports. Applications 
request report services by sending a message to the reporting 
framework. 

The following types of reports are supported by the 25 
reporting application framework: 

Scheduled: Scheduled reports are generated based upon a 
time and/or date requirement. These reports typically 
contain statistical information and are generated peri- 
odically (invoices and bills, for example). 30 

On-demand: Some reports will be requested by users with 
specific parameters. The scheduling of these reports, 
the formatting, and/or the data requirements are not 
known before the request is made, so these factors must 
be handled at request time. 

Event-driven: This report type includes reports whose 
generation is triggered based on a business or system 
event. An example here would be a printed trade slip. 
Reporting Application Framework 

FIG. 29 shows the major components of the reporting ^ 
application framework: 
Report Initiation (2900) 

The report initiation function is the interface for reporting 
applications into the report architecture. The client initiates 
a report request to the report architecture by sending a 
message to the report initiation function. The responsibility 
of report initiation is to receive, identify, and validate the 
request and then trigger the report build process. The main 
components of reporting initiation are the following. 
Receive, identify, and validate a report request The 
identification fiinction determines general information 
about the request, such as report type, requester, quan- 
tity to be printed, and requested time. Based on the 
report type, a table of reports is examined in order to 55 
gather additional report-specific information and per- 
form required validation routines for the report request. 
After the report identification and validation functions 
have been successfully completed, the reporting pro- 
cess can continue. If any errors are identified, the report go 
initiation function will return an error message to the 
requester application. 
Initiate report execution. The initiate report execution 
function proocsses the report profile and specific dis- 
tribution requirements and determines the report to be 65 
created. It then passes control to the report execution 
process. 
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Report Execution (2902) 

Report execution is the core of the reporting application 
framework. The main components of report execution 
include: 

Format the report This function is responsible for for- 
matting the layout of the outputted report, including 
standard headers, column headings, row headings, and 
other static report information. 
Collect the information. This function is responsible for 
collecting the information (for example, data, text, 
image, graphics) that is required for the report. This 
function would utilize the Information Access Services 
component of the client/server architecture. 
Format the information. This function is responsible for 
formatting the collected information into the appropri- 
ate display format based upon the report type and the 
report distribution requirements. 
Output the report. This function initiates the report dis- 
tribution function in order to distribute the created 
report to the specified devices (printers, didis, and so 
forth) and individuals. 
The process of collecting, processing, formatting, and 
outputting report data can be accomplished in several dif- 
ferent ways. For example, one method is to create a program 
in C for each report format. Here, many aspects of report 
printing — such as page size, headings, footings, and printer 
control values — would have to be programmed in function 
calls to faciUtate the report programming process. Informa- 
tion access to files or the database would be through Infor- 
mation Access Services. 

Another option is to use a third-party report tool, such as 
the SQR (Structured Query Report Writer) firom SQL Solu- 
tions. SQR is a robust report generator designed to be used 
with SQL-based relational databases. SQR insulates the 
developer from programming in a third generation language 
by providing a higher-level programming language. SQL 
queries (Information Access) are placed directly into the 
SQR program. 
Report Distribution (2904) 

The final requirement of the reporting application frame- 
work is the report distribution function. Once the report has 
been generated, it must be distributed to the ^ecified targets 
(devices and/or users). The report distribution function will 
locate completed report files and route them to the appro- 
priate devices within the client/server network. 

Typically, a report distribution database is used to specify 
the destinations for each report supported by the report 
architecture. The report distribution database specifies 
where, when, how, and to whom to distribute the produced 
report. Specific destinations can include: printer(s), user(s), 
user groups, archives (permanent storage), and/or specific 
display devices such as workstations and terminals. 

Several additional options exist for distributing reports 
including timed reporting, multiple copy distribution, and 
report archiving. Also, a user interface function can be built 
to open and browse report files. 
Custom Reporting Approaches 

If a commercially-available reporting product can not 
meet your report requirements, you may have to consider a 
custom approach. FIG. 30 illustrates an example of how a 
custom report architectiu:e relates to a wodcstation platform 
technology architecture. 

This custom report process is responsible for processing 
all messages requesting generation, manipulation, or distri- 
bution of reports. The following services are provided in an 
environment including a pair of workstations 3000 and a 
server 3002: 
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Report generation Report deletion proceeds as follows: 

Report deletion The report record is removed from the report status table. 

Report printing The report file is removed from disk. 

Report status maintenance , ^^^^^ information requests arc performed directly from 

Report generation is supported by an additional report ^^^^ InformaUon Access Services APIs No mter- 

writer process that contains all application-defined report ^^P^^ P^'^^^ necessary, which results m 

writer modules. These modules cooUin the logic to produce performance, 

each of the report types that may be requested. The report , , ^ , . . ^ 

process receives generation requests and ensures that they ^28^0^ the ino<hde hierarchy for the custom report 

are forwarded to die report writer piDcess at the current or '° P^'f.'f^- The F.gure shows the relationships between 

™ "fi-j All ^/t^ ™j :« modules, not their associated processing flows. It should be 

specinea time. All report requests are processed m an , * .„ . , , ^ , „ ^ . , 

asynchronous manner (for example, service requesters do identify the caUmg module and the called modules 

not wait for completion of report processing). f°/ P^?^ , ^P" illustrates the Architecture Manager 

HG. 31 describes the relationships between the major ^^"^^ 3200 which supporte the report process, 

components of the report process 3100 and the report writer ^he fimcUons designed to support this process are: 

process 3102. Generate Report 

Design Approach Get Report Status 

For the report process in a client/server system, a set of Control Reports 

APIs is provided for use within application programs and 20 Request Report (b2402) 

within the application report writer modules. Each API Delete Report (b2406) 

requests a specific report service (generation, printing, or Report 0>2404) 

deletion) which is perfonned by a report manager module. ^^^^^^ ^ ^^^^^ is called to request report 

The report process maintams an internal database table, a generation and printing (optional), hiput data blocks specify 

report status table, contammg information about each report 25 following 

that has been requested for generation, including: Report name 

Requesters Rejort ^^Llers 

Report name Report generation time (default is immediately) 

Date/time requested ^ ?tmt&T name. 

Status (requested, in process, complete, or error) The report name must be one of the defined application 

Report-specific parameters. report types. Valid report parameters vary depending on the 

Ihe requester ID, report name, and date/time are used to report type. Reports may be requested for generation imme- 

uniquely identify the report. These values are passed to APIs diately or at a designated future time. All reports are written 

which request report status, print or delete a previously 35 to a reserved area on disk; however, specification of a printer 

generated report. causes the output to be printed as well as stored on the file 

All application-defined report writer modules invoke an system. 

API to update the report status table with a status of Get Report Status. The Get Report Status function 

"completed" after a report has been produced or with "error" retrieves status information about all reports that have been 

if the report cannot be generated. An API is also provided to 40 previously requested for generation by the calling process, 

print the report after the generation if specified in the Returned is a list containing the requested data as well as the 

original request number of reports found. 

Processed report records are removed from the table only Control Reports. The Control Reports function is respon- 

aftcr the output reports have been archived. Implementation sible for performing various operations on reports. The 

and frequency of this table cleanup is to be determined in 45 following services are provided: 

systems management desigiL Delete a report request and any associated output 

Report Process Flows Print a previously generated report. 

Report processing is message-driven. Eacb defined API Update report status, 

sends a unique message to the report process. The report In all cases, the report name is passed through an input 

process reads the messages from a queue and invokes the 50 data block. For the print service, a printer name is passed, 

appropriate modules to handle each request. Subsequent For status update, the new status code is passed, 

process flows differ based upon the requested service. In the Request Report. The Request Report function is respon- 

case of a report generation request, the process flow pro- sible for processing report request messages written to the 

cecds as follows: report process queue. It creates a new entry in the report 

A record is added to the report status table. 55 status table with a status of "requested" and initiates the 

A message is sent to the report writer process for imme- ^^P°'^ writer process for immediate generation or sends a 

diate generation or to the event manager for generation "^^^S^ ^ ^^^^ '^^T^^'i ^""^ ^^'^ '^^""^ generation, 

at a specified time (report scheduling). ^^^^^^ ^^^^^^ ^^P°^^ function is responsible 

„ . ^ ... ^ J , for removing a report from the Report Status list and 

The appropnate apphcation report writer module gener- ^ deleting the generated output file (if any), 

ates the report, prmls U ,f specified m the origmal API j^^^ ^ finction sends a generated 

request and updates the status in the report status table. ^ ^ specified or default printer, "nie report 

A request to pnnt a report proceeds as follows: ^ requesting process ID is passed to identify the 

The report status is retrieved from the report status table. report. 

The output file is located on disk and sent to the specified 65 Evaluation Criteria 

or default printer or the request is sent to the event There arc two primary approaches to implementing a 

manager for report scheduling. reporting architecture: custom and package. Evaluating cus- 
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torn and package solutions involves both functional and 
technical criteria. The following is a discussion of various 
functional and technical criteria that should be considered 
during the planning for a report architecture. Note that not 
all of the criteria may be reqxiired by any particular organi- 
zation. 

Functional Criteria 

1. Report Repository: The report architecture should work 
with, and support maintenance of, a report repository on 
the platforms within the client/server architecture. The 
report repository contains the detailed definitions of the 
reports. 

2. Workgroup Report Support: The report architecture 
should work Avith and support distribution of reports 
generated on the workgroup server. 

3. Oo-Demand Reports: The report architecture must sup- 
port distribution of reports requested by users on demand, 
lypically, these reports will not have a set schedule or 
frequency for distribution. The report architecture must 
support distribution of these reports without the require- 
ment of manual or user intervention (subsequent to initial 
set up and conversion). 

4. Scheduled Reports: The report architecture must support 
distribution of regularly scheduled reports. Typically, 
these reports will have a set schedule and frequency for 
distribution. The report distribution package must support 
distribution of these reports without the requirement of 
manual or user intervention (subsequent to set up and 
conversion). 

5. Online Preview: The report architecture should allow 
preview of reports online from a user's intelligent work- 
station prior to actual distribution. Ideally, the report 
architecture itself would provide support for online pre- 
view of reports through software located on the intelligent 
workstation. 

6. Graphical User Interface: Ibe architecture should provide 
users with a graphical user interface. 

7. Bilingual Support: For companies where two or more 
languages are used, the report architecture must provide a 
multi-national user interface. (Note that large report runs 
targeted for multiple users may require the ability to 
change languages during the report.) 

8. Basic Preview Functions: The report architecture should 
support basic preview functions. These include: 
Scrolling up and down. 

Scrolling left and right. 

Advancing to end or beginning of report without scrolling 
through intermediate pages. 

9. Advanced Preview Functions: In addition to the basic 
preview functions Usted previously, certain advanced 
preview functions may also be necessary: 

Page indexing (allows users to jump to specific report 
pages). 

Section indexing (allows users to jump to specific report 
sections). 

Search capabilities (allows users to search report for 
occurrence of a specific data stream). 

10. Report Level Security: Reports may occasionally con- 
tain sensitive information. It is therefore important that 
access to certain reports be restricted to authorized users. 
The report architecture should provide a mechanism for 
implementing report level security. This security must be 
in place on all platforms with the client/server architec- 
ture. At the workgroup level, the security may consist of 
downloading sensitive report files to a secure directory, 
and having the LAN administrator release the report as 
appropriate. 
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11. Section, Page, and Field Level Security: Defining secu- 
rity at the report section, page, or field level wotild 
provide greater flexibility in determining and implement- 
ing report security. This is a desirable, though not 
mandatory, requirement of the report architecture. 

12. Background Processing: The report architecture should 
support the processing of reports in the background while 
the appUcation works in the foregroimd during online 
hours. In other words, processing of reports should not 
negatively afEect online response times, or tie up the 
user's workstation. 

13. Automatic Report Addressing: TTie report architecture 
should provide a "humanly intelligible" address for all 
distributed reports. The address may be used by a print 
site operator, LAN administrator, or other personnel to 
manually sort printed output (if required). This criterion 
can be satisfied by automatic creation of banner pages or 
other means. 

14. Delivery Costing: To provide sufficient information to 
users to avoid accidentally downloading or printing very 
large reports during peak usage hours, a distribution 
costing fimction can be useful. This function would warn 
users of reports that would overload the network or a 
printer. This costing function might provide recipients 
with a rough estimate of the amount of time that distri- 
bution might take. Finally, during the onUne day, the 
delivery costing mechanism might disallow transmission 
of reports that exceed a predetermined cost. 

15. Mtiltiple Destinations: The report architecture should 
support distribution of a single report to single or multiple 
destinations. 

16. Destination Rationalization: For some systems, it is 
possible that multiple copies of a report will be sent to the 
same site — to several different users, for example. In 
these cases, it is highly desirable to have the report 
architecture recognize these situations whenever possible 
and distribute the specified report only once. 

17. Automatic Printing: The report architecture should pro- 
vide automatic print capabilities. Once a report has been 
distributed for printing (either through a "push" distribu- 
tion scheduling mechanism or through a "pull" user 
request) no further user or operations personnel involve- 
ment should be necessary to print the report at the 
specified location. 

18. Multiple Print Destinations: The report architecture 
should support distribution of reports for printing at 
centralized, remote, or local print sites without user or 
operations personnel intervention. 

19. Variable Printer Types: Printing on multiple types of 
printers, including line, impact, and laser printers, should 
be supported. This should not require user intervention — 
that is, the user should not have to specify the type of 
target printer. Ideally, the report architecture would 
default this information from the user's profile or the 
default printer defined in the local operating system. This 
criterion requires that the report architecture support 
several print mechanisms, such as postscr^t drivers and 
host/mainframe protocols (for example, Advanced Func- 
tion Printing [AFP]). 

20. Variable Printer Destinations: The report architecture 
should default the destination printer for a specific report 
(from the user's profile or operating system parameters). 
Additionally, the architecture should allow the user to 
change the printer specified. Validation of the print des- 
tination ako should be included. 

21. Special Forms Printing: The report architectiire should 
support distribution of "regular** reports and special forms 
reports. 
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22. Font Support: Some reports may be printed on laser 
printers and/or may support electronic forms text (i.e., 
including the forms text in the report dataset as opposed 
to printing the report dataset on a p re-printed form). The 
architecture should allow multiple fonts to be specified. 

23. Report Archival: The report architecture should provide 
and/or facilitate archival or disposition of report datasets. 
Ideally, the architecture would permit definition of reten- 
tion periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the information contained in a report 
dataset to a user's intelligent workstation. The informa- 
tion should be in a form that can be imported to a local 
word processing software, decision support software 
package, or other appropriate appHcation. 

25. Application Transparency: It is desirable for the report 
architecture to appear to the users as if it were part of the 
overall applicatioa This does not necessarily mean that 
the architecture must integrate seamlessly with the appli- 
cation; a message interface between the systems might be 
acceptable. 

26. Selective Printing: It would be desirable for the report 
architecture to provide users with the ability to print only 
selected pages or sections of the report. This should 
reduce paper usage, while still allowing users to obtain a 
hard copy of the information as required. 

27. Print Job Restart: It would be desirable if the report 
architecture allowed a print job to be restarted from the 
point of failure rather than having to reprint the entire 
report. This of particular concern for very large reports. 

Technical Criteria 

Ihe following is a list of technical criteria that should be 
considered during the plaiming for a report architecture: 

1. Platform Compatibility: The report architecture must be 
compatible with the platform architecture. It also should 35 
be compatible with local area networks and standalone 
workstation technology specified in the platform archi- 
tecture. 

2. Wide Area Network CompatibiUty: Most systems will 
include support for WAN communication, so the report 40 
architecture should be compatible with this environment. 

3. Technology Standards: The report architecture should be 
compliant with existing formal and de facto standards (for 
example, SQL Database Language, COBOL Program- 
ming Language, C Programming Language). 

4. External User Directory: The report architecture should 
make use of an external user directory of preferences and 
locations. 

5. Data Compression in Report Repository: To reduce the 
storage requirements for the report repository, it is also 
desirable for the report architecture to support data com- 
pression in the repository. 

6. Code Page Compatibility: Code page compatibility must 
be considered when translating characters to ASCII. 

Workflow Services (2890) 

Workflow services control and coordinate the tasks that 
must be completed in order to process a business event. For 
example, at XYZ Savings and Loan, in order to receive a 
promotion, you must complete an essay explaining why you 
should be promoted. Hiis essay and your personnel file mxisl 
be routed to numerous individuals who must review the 
material and approve your promotion. Workflow services 
coordinate the collection and routing of your essay and your 
personnel file. 

Workflow enables tasks within a business process to be 
passed among the appropriate participants, in the correct 
sequence, and facilitates their completion within set times 



45 



50 



55 



65 



and budgets. Task definition includes the acdons required as 
weU as work folders containing forms, documents, images 
and transactions. It uses business process rules, routing 
information, role definitions and queues. Workflow func- 
tionality is crucial for the customer service and engineering 
applications to automate the business value chains, and 
monitor and control the sequence of work electronically. 

The business processes can be of a repetitive nature, eg 
automatically routing and controlling the review of a work 
plan through the approval stages. These are called produc- 
tion workflows. Conversely it can be an ad hoc process, eg 
generating and delivering a work order for a special meter 
reading to a meter reader who is available to perform the 
task. In production workflows the processes arc predefined, 
whereas ad hoc workflows are created only for a specific 
nonrecurrent situation. Often it is difficult to determine how 
much ad hoc functionality that needs to be provided. An 
overly strict production workflow may not support necessary 
special cases that must be handled in an ad hoc fasion. 

Workflow provides a mechanism to define, monitor and 
control the sequence of work electronically. These services 
are typically provided by the server as they often coordinate 
activities between multiple users on multiple computers. 

The following are some of the architectural and integra- 
tion issues tbat must be addressed: 
Process integration 

The workflow system must achieve a seamless integra- 
tion of mxiltiple processes. The workflow system 
must control the business process, eg it should be 
able to open a word processor with the relevant data 
coming firom a previous business process; 
Infrastructure integration from PC to mainframe 

The ability to interface with the host-based hardware, 
system software, and database management systems 
is critical. This is essential because the workflow 
system is located between the client-based and host- 
based processes, ie it can initiate client-based as well 
as host-based applications; 
LAN and WAN connectivity 

Connectivity must include all sites for the supported 
processes, enabling a large number and variety of 
users to use the workflow system, and thus to execute 
the business process; 
Integration of peripherals 

The workflow system should support many different 
types of printers, modems, fax machines, scanners, 
and pagers. This is especially important because of 
the diversity of the users that will be involved, from 
field crew to managers, each with their own needs 
and preferences; and 
Integration with workflow-participating applications 
The key to the efficiency of the workflow system is its 
capability to integrate with office automation, 
imaging, electronic mail, and legacy applications. 
Workflow can be further divided into the following com- 
ponents: 
Role management 
Role management ie provides for the assignment of 
tasks to roles which can then be mapped to individu- 
als. 

A role defines responsibiUties which are required in 
completing a business process. A business worker 
must be able to route documents and folders to a role, 
independent of the specific person, or process filling 
that role. For example, a request is routed to a 
supervisor role or to Purchasing, rather than to 
"Mary** or "Tom.** If objects arc routed to Mary and 
Mary leaves the company or is reassigned, a new 



06/17/2004, EAST Version: 1.4.1 



us 6,636,242 B2 
117 118 

recipient under a new condition would have to be istration tools. Some of the areas for monitoring for 

added to an old event. Roles are also important when improvement are employee productivity, process 

a number of different people have the authority to do performance, and forccasting^scheduling. Where any form 

the same work, such as claims adjusters; just assign of customer service is involved, features like status reports 

the request to the next available person. In addition, 5 on individual cases can sharpen customer response times 

a process or agent can assume a role; it doesn't need yj^^^^ performance monitoring of groups and individuals can 

to be a person. Role Management Services provide ^elp quality improvement and efficiency exercises. Note that 

this additional level of directory mdirection. reports and reporting does not necessarily mean paper 

Route management reports that are distributed in a traditional manner, it can 

Route management enables the routing of tasks to the 10 mean electronic messages or even triggers based on specific 

next role, which can be done in the following ways: events. 

Serial — the tasks are sequentially performed; Arc cooperative applications present? 

Parallel— the work is divided among different play- Workflow management is frequently required in coopera- 

^r^i tive applications because the users are generally 

Conditional— routing is based upon certain condi- 15 professionals, the flow of work in the organization is fre- 

lions; and qucntly highly variable, the application units of work (legal 

Ad hoc— work which is not part of a predefined case, sales order) are processed for long periods of elapsed 

process. time, and work often moves from one processing site to 

Workflow routing services route "work" to the appro- another. As data and application logic arc spUt, better control 

priate workflow queues. When an application com- 20 is needed to track processing/data status across location, 

pletes processing a task, it uses these services to wiU there be business process re-engineering? 

route the work-in-progress to the next required task Workflow is a logical complement to BPR and the trend 

or tasks and, in some cases, notify interested parties moving toward using workflow software to re-engineer 

of the resulting work queue changes. business processes on a workgroup or project basis. 

The automatic movement of information and control 25 Is the business process well defined? 

from one workflow step to another requhes work if niles or conditions can be identified which define the 
profiles that describe the task relationships for com-, business process, with few exception conditions, workflow 
pleting various business processes. The concept of tools can then automate areas such as information routing, 
Integrated Performance Support can be exhibited by task processing, and work-in-process reporting, 
providing user access to these work profiles. Such 30 Are fixed delays or deadlines involved? 
access can be solely informational — to allow the user Workflow has been used to regulate delays and deadlines 
to understand the relationship between tasks, or g^ch as those associated with government regulations, con- 
identify which tasks need to be completed for a tractual obligations, accounting periods, customer service, 
particular work flow— or navigational— to allow the and sales lead follow-up. Typical workflow goals are shorter 
user to move between tasks. 35 time to market and quicker response times. 

Route Management Services also support the routing Are multiple people involved in the business process? 
and delivery of necessary information (e.g., Workflow co-ordinates cross-functional, cross- 
documents, data, forms, applications, etc.) to the departmentalworkactivitiesandpromotesaccountability.lt 
next step in the work flow as needed. also enables dynamic redistribution and reprioritization of 
Rule Management 40 work. 

A business process workflow is typically composed of Is there a need for work scheduling? 

many different roles and routes. Decisions must be Workflow management can be extended to automate work 

made as to what to route to which role, and when. scheduling. A system may be able to do as good a job, or 

Rule Management Services support the routing of better, in scheduhng a users work. This might be due to a 

workflow activities by provic^ng the intelligence 45 very large amount of work to be assigned to a large pool, a 

necessary to determine which routes are appropriate complex method of assigning priorities, an extremely 

given the state of a given process and knowledge of dynamic environment, or some other reason. Another advan- 

the organization's workflow processing rules. Rule tage to work scheduling is that the system can initiate some 

Management Services arc typically implemented needed activity automatically for the user in anticipation of 

through easily maintainable tables or rule bases 50 the next task, 

which define the possible flows for a business event. Do integration issues exist? 

Queue Management It is important to determine how well the workflow 

These services provide access to the workflow queues system integrates with host-based hardware, system 

which are used to schedule work. In order to perform software, database management systems, and communica- 

workload analysis or to create "to do lists'* for users, 5S tion networks. Examples of items to consider include 

an application may query these queues based on E-mail, database, GUI tool, PC applications, other oflSce 

various criteria (a business event, status, assigned systems, and business appUcations. 

user, etc.). In addition, manipulation services are How scaleable is the product? 

provided to allow queue entries to be modified. Number of workers the product could reliably support in 
Workflow services allow users and management to 60 a production environment. Two major product factors char- 
monitor and access workflow queue information and acterize scalability: (1) Platform alternatives (hardware and 
to invoke applications directly. operating system); and (2) Message -based architecture 
Is there a need for reporting and management facilities? (relying on specific mail systems for much of the 
Typical workflow application requirements are better gen- fimctionality) versus Database-based, 
eral management control and better management of change. 65 What is the nature of the workflow? 
Proactive system action, audit trails and system administra- How an organization approaches the management of its 
tion features like work queue reporting are important admin- workflow wifl determine which workflow management tools 
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are appropriate to the organization. In general, there are of Presentation Services, Interface logic provides the linkage 

three types of workflow, production, collaborative, and ad that allows users to control the flow of processing within the 

hoc. A production environment involves high transaction application, 

rates and thousands of documents in which the rules for a Application Logic (b2504) 

certain document can be defined for most of the time. 5 Application Logic is the expression of business rules and 

Examples include accounts payable, insurance claims procedures (e.g., the steps and rules that govern how a sales 

processing, and loan processing. A collaborative environ- order is fulfilled). As such, the Application Logic includes 

ment involves multiple departments viewing a single docu- the control structure that specifies the flow for processing for 

ment with typically less number of documents than in the business events and user requests. The isolation of control 

production environment One example is a sales order Ad lo logic facilitates diange and adaptability of the application to 

hoc workflows arise from the specific temporary needs of a changing business processing flows, 

project team whose members become active and inactive Data Abstraction (b2506) 

depending on their function within the group. Information Access Services isolate the Business Logic 

What is the relationship between the workflow and imag- from the technical specifics of how information is stored 

ing components? 15 (e.g., location transparency, RDBMS syntax, etc.). Data 

It may be important to determine whether or not the Abstraction provides the application with a more logical 

products work routing function is integrated and inseparable view of information, further insiilating the application from 

from document storage and retrieval functions. physical information storage considerations. 

What are the necessary functions and features? The developers of business logic should be shielded from 

Issues to consider include the following: (1) samples and 20 the details and complexity of other architecture services 

assists that are available to the developer; (2) existence of a (e.g., information services, component services), and other 

scripting or programming language; (3) granularity of the business logic for that matter. 

security, or in other words, at what levels can security be It is important to decide whether the business logic will be 

added; (4) freedom of choosing productivity applications; separate from the presentation logic and the database access 

(5) existence of aggregate functions which allow for analysis 25 logic. Today separation of business logic into its own tier is 

of the workflow efficiency; (6) existence/need for Bxisiness often done using an application server. In this type of an 

ProcessiDg Re-engineering tools. environment, although some bxisiness rules such as field 

How stable is the vendor? validation might still be tightly coupled with the presenta- 

One should consider the leadership and size characteris- tion logic, the majority of business logic is separate, usually 

tics of the products vendor compared to the workflow 30 residing on the server. It is also important to decide whether 

software marketplace. Another consideration is whether the the business logic should be packaged as components in 

vendor is a member of Workflow Management Coalition. order to maximize software re -use and to streamline soft- 

This coalition is begiiming to have a bigger impact on the ware distribution. 

direction of vendors workflow management products. Another factor to consider is how the business logic is 

How mature is the product? 35 distributed between the client and the server(s) — where the 

Oneshouldconsider the age, release, and installed base of business logic is stored and where the business logic is 

the product. located when the application is being executed. There are 

How flexible is the product? many ways to distribute business logic: (1) business logic 

A product should be able to support changing workflows can be stored on the server(s) and executed on the server(s); 

at various levels of detail. 40 (2) business logic can be stored on the server(s) and 

Business Logic 1022, 1(124 executed on the client; (3) business logic can be stored and 

The execution architecture services are aU generalized executed on the client; (4) some business logic can be stored 

services designed to support the applications Business and executed on the server(s) and some business logic can 

Logic, How Business Logic is to be organized is not within be stored and executed on the client; etc. 

the scope of the execution architecture and must be deter- 45 Having the business logic stored on the server enables 

mined based upon the characteristics of the application developers to centrally maintain application code; thereby 

system lo be developed. This section is intended to serve as eliminating the need to distribute software to client 

a reminder of the importance of consciously designing a machines when changes to the business logic occur. If all the 

structure for Business Logic which helps to isolate the business logic executes on the server, then the application on 

impacts of change, and to point out that the underlying 50 the client will make requests to the server whenever it needs 

Netcentric architecture is particularly well suited for to execute a business function. This could increase network 

enabling the packaging of Business Logic as components. trafQc, which may degrade application performance. On the 

Business Logic is the core of any application, providing other hand, having the business logic execute on the client, 

the expression of business rules and procedures (e.g., the may require longer load times when the application is 

steps and rules that govern how a sales order is fulfilled). As S5 initially launched. However, once the application is loaded, 

such, the Business Logic includes the control stmcture that most processing is done on the client imtil synchronization 

specifies the flow for processing business events and user with the server is needed. This type of an architecture might 

requests. There are many ways in which to organize Busi- introduce complexities into the application that deal with the 

ness Logic, including: rules-based, object-oriented, sharing of and reliance on central data across many users, 

components, structured programming, etc. however each of 60 If the busmess logic is stored and executed on the client, 

these techniques include, although perhaps not by name, the software distribution options must be considered. Usually 

concepts of: Interface, Application Logic, and Data Abstrac- the most expensive option is to have a system administrator 

tion. FIG. 33 depicts the various components of the Business or the user physically install new applications and update 

Logic portion of the Netcentric Architecture Framework. existing applications on each client machine. Another option 

Interface Logic (3302) 65 is to use a tool that performs automatic software distribution 

Interface logic interprets and maps the actions of users functions. However, this option usually requires the soft- 

into business logic processing activities. With the assistance ware distribution tool to be loaded first on each client 
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machine. Another option is to package the application into 
ActiveX controls, utilizing the automatic instalVupdatc 
capabilities available with ActiveX controls — ^if the appli- 
cation is launched from a Web browser. 

Currently, Intemet applications house the majority of the 5 
business processing logic on the server, supporting the 
thin-client model. However, as technology evolves, this 
balance is beginning to shift, allowing business logic code 
bundled into components to be either downloaded at runtime 
or permanently stored on the client machine. Today, client lo 
side business logic is supported through the use of Java 
applets, JavaBcans, Plug-ins and JavaScript from Sun/ 
Netscape and ActiveX controls and VBScript from 
Microsoft, 

The developers of business logic should be shielded from 15 
the details and complexity of other architecture services 
(e.g., information services, component services), and other 
business logic for that matter. 

It is important to decide whether the business logic will be 
separate from the presentation logic and the database access 20 
logic. Today separation of business logic into its own tier is 
often done using an application server. In this type of an 
environment, although some business rules such as field 
validation might still be tightly coupled with the presenta- 
tion logic, the majority of business logic is separate, usually 25 
residing on the server. It is also important to decide whether 
the business logic should be packaged as components in 
order to maximize software re-use and to streamline soft- 
ware distribution. 

Another factor to consider is how the business logic is 30 
distributed between the client and the server(s) — where the 
business logic is stored and where the business logic is 
located when the application is being executed. There are 
many ways lo distribute business logic: (1) business logic 
can be stored on the server(s) and executed on the servef(s); 35 
(2) business logic can be stored on the server(s) and 
executed on the chent; (3) business logic can be stored and 
executed on the client; (4) some business logic can be stored 
and executed on the server{s) and some business logic can 
be stored and executed on the client; etc. 40 

Having the business logic stored on the server enables 
developers to centrally maintain application code; thereby 
eliminating the need to distribute software lo client 
machines when changes to the business logic occur. If all the 
business logic executes on the server, then the application on 45 
the client will make requests to the server whenever it needs 
to execute a business function. This could increase network 
traffic, which may degrade application performance. On the 
other hand, having the business logic execute on the client, 
may require longer load times when the application is so 
initially launched. However, once the application is loaded, 
most processing is done on the chent until synchronization 
with the server is needed. This type of an architecture might 
introduce complexities into the application that deal with the 
sharing of and reliance on central data across many users, 55 

If the business logic is stored and executed on the client, 
software distribution options must be considered. Usually 
the most expensive option is to have a system administrator 
or the user physically install new applications and update 
existing applications on each client machme. Another option 60 
is to use a tool that performs automatic software distribution 
functions. However, this option usually requires the soft- 
ware distribution tool to be loaded first on each client 
machine. Another option is to package the application into 
ActiveX controls, utilizing the automatic install/update 65 
capabihties available with ActiveX controls — ^if the appli- 
cation is launched from a Web browser. 
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Currently, Intemet applications house the majority of the 
business processing logic on the server, supporting the 
thin-client model. However, as technology evolves, this 
balance is beginning to shif^ allowing business logic code 
bundled into components to be either downloaded at runtime 
or permanently stored on the client machine. Today, client 
side business logic is supported through the use of Java 
applets, JavaBeans, Plug-ins and JavaScript from Sunl- 
Netscape and ActiveX controls and VBScript from 
Microsofi. 
Patterns 

Overview of Patterns 
Introducing Patterns 

The goal of patterns within the software community is to 
create a body of literatiu-e to help software developers 
resolve common difficult problems encountered throughout 
aU of software engineering and development. Patterns help 
create a shared language for communicating insight and 
experience about these problems and their solutions. For- 
mally codifying these solutions and their relationships lets 
us successfully capture the body of knowledge which com- 
prises one's understanding of good architectures that meet 
the needs of their users. Forming a common pattern lan- 
guage for conveying the structures and mechanisms of 
architectures allows us to intelUgibly reason about them. The 
primary focus is not so much on technology as it is on 
creating a culture to document and support sound engineer- 
ing architecture and design. 

What is a Pattern? 

A pattern is a named nugget of insight that conveys the 
essence of a proven solution to a recurring problem within 
a certain context amidst competing concerns. Patterns are a 
more formal way to document codified knowledge, or rules- 
of-thumb. 

Patterns represent the codified work and thinking of our 
object technology experts. While experts generally rely on 
mental recall or rules-of-thumb to apply informal patterns as 
opportimities are presented, the formahzation of the patterns 
approach allows uniform documentation and transfer of 
expert knowledge. 

Patterns are not unique lo object technology or even 
software development, having been invented by Christopher 
Alexander, a building architect. However, they have not 
been applied to other information technology development 
techniques. Thus, they are an exclusive featxire of object 
technology. Furthermore, patterns are becoming widely 
accepted by the worldwide object conmiunity as an impor- 
tant element in successfully rolling out the technology, and 
enabling the maturation of software development as an 
engineering process. 

Patterns are usually concerned with some kind of archi- 
tecture or organization of constituent parts to produce a 
greater v^ole. Richard Gabriel, author of Patterns of Soft- 
ware: Tales From the Software Community, provides a clear 
and concise definition of the term pattern: 
Each pattern is a three-part rule, which expresses a 
relation between a certain context, a certain system of 
forces which occurs repeatedly in that context, and a 
certain software configuration which allows these 
forces to resolve themselves. 
As an element in the world, each pattern is a relationship 
between a certain context, a certain system of forces 
which occurs repeatedly in that context, and a certain 
spatial configuration whidi allows these forces to 
resolve themselves. 
As an element of language, a pattern is an instruction, 
which shows how this spatial configuration can be 
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used, over and over again, to resolve the given system Management Considerations section of the Introduction to 
of forces, wherever the context makes it relevant. Component-Based Development uses the Business Integra- 
Hie pattern is, in short, at the same time a thing, which tion (BQ Model to discuss the impact of 00, including: 
happens in the world, and the rule which tells us how Strategy and planning with a long-term view towards 
to create that thing, and when one must create it. It is ^ building reusable, enterprise software assets, 
both a process and a thing; both a description of a thing Technology and architecture approaches for building 
which is alive, and a description of the process which cohesive, loosely coupled systems that provide long- 
may generate that thing. tenn flexibility. 
In Software Patterns, Jim Coplknvni^^^ Processes that shift analysis/design techniques from 



may do the following: 



functional, procedural decomposition to business pro- 



It solves a problem: Patterns capture solutions, not just ^ess modeling. These techniques are then used to 
abstract principles or strategies. decompose the system into domain objects and pro- 
It is a proven concept: Patterns capture solutions with a cesses. 

track record, not theories or speculation. People and organization strategies that emphasize greater 

The solution isn^t obvious: Many problem-solving tech- specialization of skills within structures that support 

niques (such as software design paradigms or methods) inter-team collaboration. 

try to derive solutions from first principles. The best Balancing Tradeoffs is Key to Applying Components for 

patterns generate a solution to a problem indirectly — a Mission-critical Systems 

necessary approach for the most difficult problems of Tradeoffs are an important theme. Experience with large, 
design, mission-critical systems has shown that the most complex 
It describes a relationship: Patterns don't just describe issues require strategic tradeofife between quality, cost, and 
modules, but describe deeper system structures and time. These tradeoffs usually involve interdependent con- 
mechanisms, siderations between strategy, technology, process, and 

The pattern has a significant human component All 25 people. See FIG. 34 which illustrates a relationship between 

software serves human comfort or quaUty of life; the major themes. For example, how should an architecture be 

best patterns explicitly appeal to aesthetics and utility tailored to effectively support a specific methodology, for a 

Component-based Development given organization's skill set? Competing tensions also 

Introduction to Component Based Development cloud decisions at a more detailed level For example, how 

Component systems model—how the business works 30 should an architecture be customized to better support 

Component-orientation is a strategic technology that may performance, at the potential cost of increased coupling 

significantly impact a user's practice and clients. Compo- between components? 

nent technologies are a natural evolution from object- Many of these considerations have been addressed over 

oriented systemsproviding a more mature way of packaging last few years. Most published literature continues to 

reusable software units. Object-oriented systems more 35 focus on narrow technology issues, such as programming 

closely support business integration framework for solution techniques or generic methodologies, such as analysis and 

delivery by shifting design focus away from an underlying design approaches or notation. Still, a growing number of 

tedmology toward a company's business conduct and func- publications and vendor strategies attack the enterprise 

tional behaviors. Business entities are represented as objects, needs within on-line netcentric execution models. Real- 

which package data and functional behavior. This is in 40 world, client solutions involve making pragmatic decisions, 

distinct contrast to traditional development approaches that ^ which compromise occurs at the intersection of the four 

maintain a ubiquitous split between fimctional behaviors and major 00 themes. Experience with many component client 

data. projects in diverse industries uniquely positions a user to 

Object-orientation has accelerated into the take-up curve. effectively address these complexities. 

All of the major commercial component models are object- 45 Management Considerations Overview 

oriented. In addition, all of the major vendors have adopted Management Considerations section discusses the 

the "Unified Modeling Language" (UML) as a standard key benefits, risks, and issues introduced by a component 

noution for describing object models. A tremendous reser- engagement. Key topics include: 

voir of knowledge capital, practice aids and starter kits Managing risk in balancing tradeoffs between strategy, 

related to object and component technology can be found on so people, process, and technology 

the Knowledge Exchange. Considering issues related to configuration management. 

More and more, users are asking for assistance to deploy testing, and performance of object systems 

Netcentric eCommerce appUcations based on components^ Addressing the component development learning curve 

These applications are frequently based on object-oriented , 

languages like Java, Visual Basic and C++. 55 differences between development architecture consider- 

Objects are an easy metaphor to understand and manage. ations leveraging the advantages of a component indus- 

There are still substantial risks involved, particularly -i . 

because component- and object-orientation has a pervasive . Management Considerations secUon also address 

impact on areas as broad as analysis and design, planning, '^"^ Component technology, mcluding: 

and development tools. 60 Estimating, planning, and managing iteration 

Component-based Overview Organizing and managing to achieve reuse of both archi- 

Component Technology Impacts Most Aspects of Develop- tecture and business logic 

ment Netcentric Patterns Overview 

Component and object technology impacts most a^ects Netcentric Patterns Focus on Application Frameworks 

of software development and management. Component 65 Netcentric Patterns focus on how to design and leverage 

technology is a new technology and a driving influence in application frameworks, which are pieces of reusable appli- 

the evolution of object-oriented (00) methodologies. The cation architecture that provide a highly configurable, flex- 
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ible and maintainable system. They are aligned with SAF trated inFIG. 35. Some of them — typically designers — take 

and/or DAF service layers. Alignment with SAF and/or a logical perfective. They view components as a means for 

DAF makes the patterns easier to grasp the context for which modeling real-world concepts in the business domain. These 

they are solving problems. are Business Components. Others — typically developers — 

There was no mandate to express implementation within 5 take a physical perspective. They view components as 

any given particular 00 language. Java and Visual Basic independent pieces of software, or application building 

have increased in popularity over the last few years and C++ blocks, that implement those real-world business concepts, 

continues to be a solid foundation on which to build many ^hese are Partitioned Business Components. Developers 

types apphcaUons. In addition, some implementations chose emphasize that Partitioned Business Components can 

the design syntax of UML. One should see the va^^^ ^^^^^ independent pieces of software that 

pattern regardless of the implementation personality. - ,. .K ^. 

Nowhere l^s this been more strongly demonstrated than in Provide ftmctionality that is generally useful across a wide 

the Eagle Starter Kits. Here, the Eagle Architecture Speci- applications. Tbesc are Engineering Components 

fication has been documented in patterns and implemented . To use m analogy, the desi^er of a PC workstation woul^ 

in Visual Basic, Java, C++ and a host of execution environ- "^i^^ally think m terms of logical components such as Disk 

ments within these language offerings. The power is in the Storage, Memory, Display, etc. These are analogous to 

reusable design patterns. Business Components. At some point in the design process, 

For a high-level description of the context for the patterns however, ibis thinking must become more precise. For 

within a service layer of SAF and/or DAF, click the title of example, Disk Storage might become a Hard Disk Drive and 

the section. Please refer to the SAF and/or DAF for more Disk Controller Card. These are analogous to Partitioned 

detailed descriptions of the service layers. From the Frame- 20 Business Components. And finally, the designer might use 

works Main Page, under Framework Extensions, the "Com- generic parts in the design of the Disk Controller Card, such 

ponent Technology Extension" describes, in the context of as Memory Chips for cache, Bus Adapters, etc. These arc 

the Netcentric Architecture framework, the additional, analogous to Engineering Components, 

specialized, architecture services that are required when Establishing one definition to satisfy all of these perspec- 

building a system using component technologies. 25 tives is certainly not required to be successful with compo- 

Approach nents. What's more important is to recognize the different 

Over the past years, component-based development has perspectives and to understand when it's appropriate to talk 

become an important, but often-misunderstood concept in about a particular type of component. Hence, multiple 

the IT world. Components in themselves don't guarantee definitions, one for each type of component: 

successful business applications, but coupled with a proven 30 Business Components represent real-world concepts in 

methodology and continuous technological advancements, the business domain. They encapsulate everything about 

they make it possible to reatize a number of important those concepts including name, purpose, knowledge, 

benefits such as flexibility, adaptability, maintainability, behavior, and all other intelligence. Examples include: 

reusability, integration readiness, interoperability, and seal- Customer, Product, Order, Inventory, Pricing, Credit Check, 

ability. 35 Billing, and Fraud Analysis. One might think of a Business 

Components have been around for a long time. The Component as a depiction or portrait of a particular business 

wheels on an ancient Roman chariot were certainly compo- concept, and as a ^»1iole, the Business Component Model is 

nents. When the local chariot maker invented a new wheel a depiction or portrait of the entire business. It's also 

(one that promised greater speeds and improved reliability important to note that although this begins the process of 

on a wider variety of terrain), chariot owners would replace 40 defining the application architecture for a set of desired 

their wora-out, inefficient, and out-dated wheels with the business capabilities, the applicability of the Business Com- 

new ones, but only if the new ones offered, at a minimum, ponent Model extends beyond application building, 

the same function (i.e., rolling) through the same interface Whereas Business Components model real-world con- 

(Le., the connection between the wheel and the chariot). cepts in the business domain, Partitioned Business Compo- 

Today components are used to build everything from cars 45 nents implement those concepts in a particular environment, 

to computers. In electronics, for example, they have led to They are the physical building blocks used in the assembly 

the proliferation of product features, disposability, of applications. As independent pieces of software, they 

miniaturization, product selection, price reduction, and Stan- encapsulate business data and operations, and they fulfill 

dard interfaces — all good for the consumer. This example distinct business services through well-defined interfaces, 

also draws attention to some of the challenges that accom- so Business Components are transformed into Partitioned Busi- 

pany components: setting standards, determining the right ness Components based on the realities of the technical 

components, the need to change standard interfaces based on environment: distribution requdrements, legacy integration, 

new requirements, and the legal and commercial structure performance constraints, existing components, and more, 

for selling components. For example, a project team might design an Order Business 

Hiroughout the industry the word "component" is used 55 Component to represent customer demand for one or more 

broadly and often loosely. Components come in a wide products, but when it*s time to implement this concept in a 

variety of shapes and sizes. For example: JavaBeans, particular client/server environment, it may be necessary to 

ActiveX controls, and COM objects. And more generically: partition the Order Business Component into the Order 

application, architecture, development, engineering, Web, Entry component on the client and the Order Management 

server, and business components. 60 component on the server. These are Partitioned Business 

Many industry experts have attempted to define "compo- Components, 
nent." Unfortunately, many of these definitions are too Engineering Components are independent pieces of soft- 
abstract, too academic, or too specialized to be useful. Yet ware that provide functionality that is generally useful 
below the surface of these definitions is some real business across a range of applications. They come in all shapes and 
value for organizations. 65 sizes, and they are typically packaged as black box capa- 

Experiencc has shown that it's quite common for people bilities with well-defined interfaces. They are the physical 

to view components from different perspectives, as illus- building blocks used in the assembly of Partitioned Business 
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Components. Examples include: a workflow engine, a Java- 
Bcan that encapsulates a reusable concept like address or 
monetary unit, a complex widget that allows users to edit a 
list of order lines, a group of objects responsible for 
persistence, a JavaBean that sorts a collection of objects, and 5 
a simple list box coded as an ActiveX control. 

Components arc useful throughout the development pro- 
cess. As a design artifact, early in the process, Business 
Components provide an underlying logical framework for 
ensuring flexibility, adaptability, maintainability, and reus- lO 
ability. They serve to break down large, complex problems 
into smaller, coherent elements. They also model the busi- 
ness in terms of the real-world concepts that make up the 
domain (e.g., entities, business processes, roles, etc.). Thus 
they provide the application with conceptual integrity. That 15 
is, the logical Business Components serve as the direct link 
between the real-world business domain and the physical 
application An important goal is to build an application that 
is closely aligned with the business domain. Later in the 
process. Partitioned Business Components and Engineering 20 
Components provide a means for implementing, packaging, 
and deploying the application. They also open the door to 
improved integration, interoperability, and scalabflity. 

HG. 36 shows a relationship between business compo- 
nents 3600 and partitioned business components 3602. Busi- 25 
ness Components are an integral part of the previously 
discussed Framework Designs. Business Components rep- 
resent real- world concepts in the business domain. They 
encapsulate everything about those concepts including 
name, purpose, knowledge, behavior, and all other intelli- 30 
gence. 

In the Business Architecture stage 3604, a project team 
begins to define the application architecture for an organi- 
zation's business capabilities using Business Components. 
Business Components model real-world concepts in the 35 
business domain (e.g., customers, products, orders, 
inventory, pricing, credit check, billing, and fraud analysis). 
This is not the same as data modeling because Business 
Components encapsulate both information and behavior. At 
this point in the process, an inventory of Business Compo- 40 
nents is suflHcienl, along with a definition, list of entities, and 
list of responsibilities for each Business Component. 

In Capability Analysis 3606and the first part of Capability 
Release Design 3608, the project team designs Business 
Components in more detail, making sure they satisfy the 45 
application requirements. The team builds upon its previous 
work by providing a formal definition for each Business 
Component, including the services being ofiered. Another 
name for these services is "Business Component Interfaces." 
The team also models the interactions between Business 50 
Components. 

Throughout the remainder of Capability Release Design 
and into Capability Release Build and Test 3610, Business 
Components are transformed into Partitioned Business 
Components based on the realities of the technical environ- 55 
menl. These constraints include distribution requirements, 
legacy integration, performance constraints, existing 
components, and more. Furthermore, to ensure the concep- 
tual integrity of the Business Component model, a given 
Partitioned Business Component should descend from one 60 
and only one Business Component. In other words, it should 
never break the encapsulation already defined at the Busi- 
ness Component level. Also at this time, the project team 
designs the internal workings of each Partitioned Bxisiness 
Component. This could mean the Engineering Components 65 
that make up the Partitioned Business Component, the 
"wrapper*' for a legacy or packaged system, and other code. 
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In Capability Release Build and Test, Partitioned Business 
Components arc built and tested. The build process varies 
depending i^on the technology chosen to build the intemal 
workings of each Partitioned Business Component. Among 
the many tests that are performed during this stage, the 
component, assembly, and performance tests are impacted 
the most by this style of development. A component test 
addresses a Partitioned Business Component as a single unit 
by testing its interfaces and its internal workings, while an 
assembly test addresses the interactions between Partitioned 
Business Components by testing broader scenarios. The 
performance test is impacted primarily by the techniques 
one would use to resolve the various performance issues. For 
example, it's common to run multiple copies of a Partitioned 
Business Component across multiple servers to handle a 
greater transaction volume. 

In Deployment 3612, the Partitioned Business Compo- 
nents are packaged and deployed as part of the application 
into the production environment The application parameters 
and the manner in which the Partitioned Business Compo- 
nents are distributed are tweaked based on how well the 
application performs. 

Well designed Business Components are anthropomor- 
phic. That is, they take on characteristics and abilities as if 
they were alive. This means that Business Components 
should reflect directly the characteristics and abilities (i.e., 
the information and behavior) of the business concepts they 
represent. Therefore, only by examining the various types of 
business concepts will one discover an acceptable way to 
classify Business Components. 

Business concepts come in a wide variety. For example, 
a product represents something of value that is up for sale, 
while a credit check represents the work that needs to be 
done to determine if a customer's credit is good. The former 
is centered around an entity — the product — while the latter 
is centered aroimd a process — credit check. 

This line of thinking leads to two types of Business 
Components: entity-centric and process-centric. 
Unfortimately, what commonly results from this paradigm is 
an argument over whether or not a particular Business 
Component is entity-centric or process-centric. In reality. 
Business Components are always a blend of both informa- 
tion and behavior, although one or the other tends to carry 
more influence. An appropriate mental model is a spectrum 
of Business Components. 

Business Components on the entity-centric side of the 
spectrum tend to represent significant entities in the business 
domain. Not only do they encapsulate information, but also 
the behaviors and rules that are associated with those 
entities. Examples include: Customer, Product, Order, and 
Inventory. A Customer Business Component would encap- 
sulate everything an organization needs to know about its 
customers, including customer information (e.g., name, 
address, and telephone number), how to add new customers, 
a customer's buying habits (although this might belong in a 
Customer Account component), and rules for determining if 
a customer is preferred. 

Business Components on the process-centric side of the 
spectrum tend to represent significant business processes or 
some other kind of work that needs to be done. Not only do 
they encapsulate behaviors and rules, but also the informa- 
tion that is associated with those processes. Examples 
include: Pricing, Credit Check, Billing, and Fraud Analysis. 
A Pricing Business Component would encapsulate every- 
thing an organization needs to know about how to calculate 
the price of a product, including the product's base price 
(although this might belong in a Product component), dis- 
counts and rules for when they apply, and the calculation 
itself. 
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One might argue that the Pricing component is more 
entity-centric than process-centric. After all, it's centered 
around the concept of price, which is an entity. In reality, 
thou^, it depends on the business requirements, but again, 
whether or not a given Business Component is entity-centric 
or process-centric is not important yet. What is important is 
how well the Business Component represents its corre- 
sponding real-world business concept. The fact that most 
business concepts are a blend of information and behavior 
means that most Business Components should also be a 
blend of information and behavior. Otherwise applications 
would be mudi like they are today with a distinct separation 
of data and process. 

Another way to think about the process-centric side of the 
spectrum is by asking, "What role performs the process?" 
For example, it's the picker-packer who picks inventory and 
packs it into a shipment. This might lead to the Picker- 
packer component. Another example is a Shopping Agent 
component that knows someone's buying preferences, shops 
for the best deals, and either reports back to the user or 
makes the purchase. 

A pattern emerges when one examines the way these 
Business Components interact with each other. Process- 
centric Business Components are "in control," while entity- 
centric Business Components do what they're told. To be 
more exphdt, a process-centric Business Component con- 
trols the flow of a business process by requesting services in 
a specific sequence according to specific business rules (i.e., 
conditional statements). The services being requested are 
generally offered by entity-centric Business Components, 
but not always. Sometimes process-centric Business Com- 
ponents trigger other process-centric Business Components. 

FIG. 37 shows how a BilUng Business Component 3700 
may create an invoice. The control logic 3702 (i.e., the 
sequence of steps and business ruies) associated with the 
billing process is encapsulated within the Billing component 
itself. The Billing component requests services from several 
entity-centric Business Components, but it also triggers 
Fraud Analysis 3704, a process-centric Business 
Component, if a specific business rule is satisfied. Note also 
that "Step 6" is performed within the Billing component 
itself. Perhaps this is where the invoice is created, reflecting 
the design team's decision to encapsulate the invoice within 
the B illing component. This is one valid approach. Another 
is to model a separate entity-centric Invoice component that 
encapsulates the concept of invoice. This would effectively 
decouple the invoice from the billing process which might 
be a good thing depending on the requirements. 

It would be logical to conclude that the two types of 
Business Components translate to two types of Partitioned 
Business Components, but a small adjustment is required. 
Entity-centric Business Components translate directly to 
Business Entity Components, but a closer look at the ways 
in which a biisiness process can be implemented in an 
appUcation reveals two possibilities for process-centric 
Business Components. A business process can be: 1) 
automated, like a bifling process, or 2) controlled by a user, 
Uke an order entry process. The former results in a Bxisiness 
Process Component, while the latter results in a User Inter- 
face Component. 

FIG. 38 illustrates the relationship between the spectrum 
of Business Components 3800 and the types of Partitioned 
Business Components 3802. Business Entity Components 
3804 and Business Process Components 3806 are straight- 
forward. The former is the physical implementation of an 
entity-centric Business Component (e.g.. Customer), while 
the latter is the physical implementation of an automated 
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process-centnc Business Component (e.g., Bifling). User 
Interface Components 3808, on the other hand, require 
further explanation. 
As mentioned above, a User Interface Component is the 

5 implementation of a busuiess process that is user controUed, 
but more expflcitly it is a set of functionafly related windows 
that supports the process(es) performed by one type of user. 
Examples include: Customer Service Desktop, Shipping 
Dedctop, and Claim Desktop. These are not to be confUsed 
with low-level user interface controls (e.g., Active X 
controls), rather User Interface Components are usually built 
from low-level user interface controls. The reason for the 
dashed arrow in the diagram above is a subtle one. It points 
to the fact that earlier in the development process User 
Interface Components are gcneraUy not modeled as process- 
centric Business Components. Instead, they typicaUy origi- 
nate from the workflow, dialog flow, and/or user interface 
designs. See FIG. 39, which iUustrales the flow of workflow, 
dialog flow, and/or user interface designs 3902, 3904, 3906 
to a User Interface Component 3908. This makes complete 

20 sense given their direct tie to user controlled business 
processes, 

FIG. 40 is a diagram of the Eagle Application Model 
which illustrates how the different types of Partitioned 
Business Components might interact with each other, Busi- 

25 ness Entity Components 4002 and Bxisiness Process Com- 
ponents 4004 typically reside on a server, while User Inter- 
face Components 4006 typicafly reside on a client. 

FIG. 41 iUustrates what makes up a Partitioned Business 
Component 4100. As long as a component does what it's 

30 suppose to do, it doesn't matter what kind of code is used to 
build the component's internal workings. It could be any- 
thing from COBOL to Java. This is a key benefit of 
encapsulation. Classifying this code is a different matter. 
Some code 4102 is specific to the Partitioned Business 

35 Component. Other code is more widely reusable, both 
functionally and technically; this is where one finds Engi- 
neering Components 4104, Another possibflity is to "wrap" 
existing code 4106 from legacy and packaged systems. 
Finally, it's important to note that patterns and frameworks 

40 are firequently used as starting points for designing and 
building this code. 

Engineering Components are physical building blocks 
used in the assembly of Partitioned Business Components. 
They are independent pieces of software that provide func- 

45 tionality that is generally useful across a range of 
applications, and they are usually packaged as black box 
capabiUties with wefl-defined interfaces. Engineering Com- 
ponents can be bought or built, and they come in a wide 
variety. Examples include: a workflow engine, a JavaBean 

50 that encapsulates a reusable concept like address or mon- 
etary value, a complex user interface control that allows 
users to edit a list of order lines, a group of objects 
responsible for persistence, a JavaBean that sorts a coUec- 
tion of objects, and a list box coded as an ActiveX control. 

55 A pattern is "an idea that has been useful in one practical 
context and wiU probably be useful in others." Think of them 
as blueprints, or designs for proven solutions to known 
problems. Having found the right pattern for a given 
problem, a developer must then apply it. Examples of 

60 patterns include: an analysis pattern for hierarchical rela- 
tionships between organizations and/or people, a design 
pattern for maintaining an audit trail, a design pattern for 
applying different levels of security to different user types, 
and a design pattern for composite relationships between 

65 objects. 

A framework is a template for the implementation of a 
particular function (similar to a shell program). It usuafly 
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embodies a known pattern (or group of patterns) in a specific 
technical environment. Frameworks arc available from a 
number of third-party vendors, and they are also developed 
on projects. Developers are typically expected to customize 
and extend firameworks to meet their specific requirements^ 
but this involves a tradeoff. Customizing and extending a 
framework may optimize its use, but the resulting fi:ame- 
work tends to be less abstract, and therefore less reusable in 
other contexts. Examples of frameworks include: a frame- 
work for displaying an object and its properties in Smalltalk, 
a Java-specific framewodc for persisting data, and a mes- 
saging and publish/subscribe framework for DCOM. 

FIG. 42 illustrates the role of patterns and frameworks. 
More specifically, it introduces the Eagle Architecture 
Specification 4200 and the Component Solutions Handbook 
4202, both of whicb are groups of patterns. Eagle also offers 
technology-specific starter Idts 4204, which include frame- 
works for various environments. 

The pace of change in today's business world is increas- 
ing faster than ever before. Meanwhile, advances in infor- 
mation technology have enabled businesses to better under- 
stand their customers, provide greater value, and create dew 
markets. However, as technology becomes more complex, 
applications have become more difiScult and time- 
consuming to build and maintain. Looking forward, appli- 
cations must be dramatically more responsive to change. 
They must be more: 



In theory , 



In practice . 



Making it pos&ibLe to accom- 
modate a new product line 
solely by updating th& Product 
component. 



Rexible Making it possible to 

quickly satisfy new busi- 
ness requirements by 
replacing or modifying 
certain components with 
miaimat impact to others. 
Adaptable Making it easy to deliver an Making it eaisy to provide in- 
application to a variety of home access to customer 
user types through a variety account information by 
of delivery channels with developing only a new user 
minimal impact to the core interface while reusing 
application. existing components. 

Maintainable Making it easy to update an Making it easy to add a new 
application by reducing the customer attribute by isolating 
the change to one compon- 
ent - the Customer compon- 
ent 

Reusable Making it possible to Making it possible to as- 

semble an application at a 



area of impact for most 



Making it possible to 
quickly assemble unique 

and dynamic solutions from fraction of the cost because 
existing components. 



Integration 
Ready 



Making it possible to reuse 
the functionality within 
existing systems by wrap- 
ping them as ocmpoaeats 
within new applicatioos. 
Interoperable Making it possible to 
request services across 
platforms. 

Scalable 



10 



15 



20 



25 



30 



eight of the twelve compo- 
nents that are needed already 
exist. 

Making it possible to absorb 
newly acquired divisioas by 
"wrapping" their systems and 
'plugging" them into the 
enterprise infrastructure, 
Making it possible to integrate 
two applications built on 
different platforms. 
Making is easy to distribute Making it easy to accom- 
and reconfigure compo- modate the holiday crunch by 
nents to satisfy various running multiple copies of the 
transaction volumes. Order component across 

multiple servers. 



Components wiU help an IT organization achieve these 
quality attributes. Through encapsulation they make it pos- 
sible to develop applications that are more responsive to 
change. One can m^e this claim with confidence because a 
component that is well encapsulated (i.e., an independent, 
black box component with predictable, well defined 
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40 



45 



50 



55 



65 



interfaces) can be used in any situation, as long as it's used 
for its intended purpose. It knows how to perform its 
services without regard to what's happening outside of its 
boundaries (e.g., the actions that precede or follow it). 

Another key to embracing change is the predictability and 
conceptual integrity of the parts that make up an application, 
Fred Brooks, author of The Mythical Man-Month, writes, 
. . conceptual integrity is the most important consideration in 
system design." Therefore, components must be conceptu- 
idly whole, and they must perform functions that are aligned 
with their purpose and within their sphere of knowledge. If 
they accurately reflect the real world, they are much easier 
to develop and maintain. If the real world changes, so must 
the corresponding component. 

Given a design with these characteristics, the opportunity 
for reuse is significantly enhanced, and the time it takes to 
upgrade the system is dramatically reduced. The Gartner 
Group agrees that component-based development wiU be a 
dominant method of application development in the years to 
come. They say that "by 2001, at least 60 percent of aU new 
applications development will be based on assemblies of - 
componentware, increasing speed to market and the ability 
to cope with change (0.7 probability).'* 

Business Components and Partitioned Business Compo- 
nents represent a major improvement in design capability — 
some might argue the first major change in design thinking 
since structured design. There are several reasons for this 
breakthrough: 

Business Components model entities and processes at the 
enterprise level, and they evolve into Partitioned Business 
Components that are integrated into applications that operate 
over a network. Consequently, they serve as an excellent first 
step in the development of scalable, distributed enterprise 
applications that map closely to the bxisiness enterprise itself 
(i.e., the way it operates and the information that defines it). 

Business Components model the business, and thus they 
enable apphcations to more completely satisfy the business 
needs. They also provide a business-oriented view of the 
domain and consequently a good way to scope the solution 
space. TMs results in a good context for making process and 
application decisions. Finally, Business Components pro- 
vide a common vocabulary for the project team. They 
educate the team in what's important to the business. 

When modeled correctly, entity-centric Business Compo- 
nents represent the most stable elements of the business, 
while process-centric Business Components represent the 
most volatile. Encapsulating and separating these elements 
contributes to the application's overall maintainability. 

To manage the complexity of a large problem, it must be 
divided into smaller, coherent parts. Partitioned Business 
Components provide an excellent way to divide and conquer 
in a way that ties the application to the business domain. 
They provide the ability to "package software capabilities 
into more manageable (and useful) chunks.** By contrast, 
traditional modiiles are too cimibersome to be reusable in 
multiple contexts. On the other end of the spectrum, objects 
are too small to effectively divide and conquer; there are 
simply too many of them. 

Partitioned Business Components provide a greater 
emphasis on application layering — a well known, but often 
neglected concept in application development 

Partitioned Business Components are application building 
blocks. As an application modeling tool, they depict how 
various elements of an application fit together. As an appU- 
cation building tool, they provide a means for systems 
delivery. 

Proven processes, patterns, and frameworks offer a higher 
level of reuse. This is one of the key advantages because it 
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means greater agility. These mechanisms make it possible 
for hundreds of developers to do things consistently and to 
benefit from previously captured, reusable knowledge capi- 
tal. 

Business Components model the business. It sounds 
straightforward, but even with experience it's a challenge to 
identify the right components and to design them for flex- 
ibility and reuse. Flexibility and reuse are certainly more 
achievable with Business Components, but they are not 
inherent to Business Components. To accomplish these 
goals, as the previous examples suggest, one must under- 
stand what's happening within the enterprise and across the 
industry. One must work with business experts who under- 
stand the factors that will influence the current and future 
evolution of the business domain. This will improve one's 
ability to anticipate the range of possible change (i.e., to 
anticipate the future). The Business Component Model will 
be more flexible and reusable if it is challenged by scenarios 
that are likely to take place in the future. 

Reuse becomes a reality more quickly if one plans for it. 
And it endures if one manages it over time. However, both 
of these things are difficult to do, especially for large projects 
and large enterprises. First of all, it's easy for communica- 
tion across one or more projects to break down. It's also 
common for individual projects to pay more attention to 
their requirements and deadlines than to project-wide or 
enterprise -wide reuse. After all, their most important objec- 
tive is to deliver value to their customers. Reuse must be 
engrained into the culture. This could mean teams respon- 
sible for project-wide and enterprise-wide reuse, but no 
matter how it's done, reuse must be one of the most 
important technology objectives. 

Too much focus on low-level (i.e., code) reuse can be a 
trap. To draw an analogy, take a look at the recent history of 
the auto industry. Some auto makers were focused on 
inter-changeable parts and low-level standardization. For 
example, they decided to use the same body style for all of 
their cars. Unfortunately, when the industry began to move 
away from the boxy body style, they were not well prepared, 
nor were they agile enough to react in a timely fashion. They 
had invested too much in low -level standardization. 
Conversely, other auto makers were focused on quality 
processes and frameworks (i.e., high-level reuse). As a 
result, they were able to respond more quickly to the 
changing requirements. Engagement experience has shown 
that the same thing can happen with components and objects 
(e.g., too much emphasis on low-level inheritance). That's 
why it's important to focus appropriately on the high-level 
reuse enabled by processes, patterns, and frameworks. 

Although Business Components and Partitioned Business 
Components represent a significant breakthrough in design 
capabiUty, the architectural frameworks to support this 
breakthrough are still maturing. Standards come to mind 
first: Will it be COM, JavaBeans, or CORBA? It's still not 
clear. Likewise with languages: Will it be Visual Basic, 
Java? Tools and repositories offer another challenge. Clear 
winners have yet to emerge, and newcomers are constantly 
popping up with promising products. Finally, the legal and 
commercial market for buying and seUing components is not 
mature. The market for high-level common business objects 
is just emerging, while the market for low-level components 
is still chaotic. 

One of the most important challenges is teaching a new 
application development style. Although components and 
objects have been around for a while, they are new to most 
people. Furthermore, component-based development 
requires a change in the way one thinks about designing and 
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building applications. Engagement experience has shown 
that it lakes a couple of months to feel comfortable with this 
paradigm — and longer for those pursuing deeper technical 
skills. But this challenge is certainly not impossible to 
5 overcome. A combination of training and mentoring has 
proven to be the best way to teach these concepts, and the 
more rigorous approach that results from this education is 
weU worth the journey. 

The following tips and techniques provide an introduction 
to some of the issues surrounding the design of Business 
Components. 

Wh&X is the right number of Business Components? How 
big should they be? 

The granularity of Business Components is a frequent 
topic of discussion. A fairly common misconception is that 

15 Business Components are the same as applications, but in 
fact, appHcations are assembled from Business Components 
(or Partitioned Business Components to be more accurate). 
A typical application might have ten to twenty Business 
Components. On the other end of the spectrum. Business 

20 Components are larger than business objects. In fact, some 
people refer to Business Components as large-grained busi- 
ness objects. 

So what is the right size for a Business Component? 
Business Components should encapsulate concepts that 

25 are significant to the business domain. Of course, this is 
subjective, and it certainly varies by business domain. In 
fact, business domain experts, with help from component 
modelers, are in the best position to make this judgment. 
Bigger Business Components hide more complexity, 

30 which in general is a good thing. However, too much 
complexity in a component can lead to many of the is 
problems that preceded component-based development. For 
example, embedding too much policy information can lead 
to a Business Component that is more difficult to maintain 

35 and customize. Another advantage is the fact that the cou- 
pling between bigger components tends to be weaker. On the 
other hand, bigger components are generally less cohesive 
and consequently less flexible. For example, assume that the 
concepts of warehouse and inventory have been combined 

40 into one Business Component. This could be problematic if 
a friture application needs warehouse information, but not 
inventory information. 

Smaller Business Component tends to be more flexible. 
It's also easier to reuse them in future applications. 

45 Unfortunately, smaller components typically result in a 
higher degree of coupling. One will find significantly more 
interactions between smaller components. This could also 
lead to performance problems. If two or three small com- 
ponents send each other a lot of messages, it might make 

50 sense to combine them into one. Smaller components may 
also be more difficxilt to manage, simply because more of 
them exist 

It's important to strike a balance, and keep in mind that 
the ideal size depends on the domain. If there's a question 
55 in one's mind, it makes sense to lean toward smaller 
components. It's easier to combine them than to break them 
up. 

What's the best way to identify Business Components? 

During the Business Architecture stage, the project team 
60 defines its business capabilities. At this point in the process, 
one can begin to search the business domain for Business 
Components. Then again later, during Capability Release 
Design, when the project team documents scenarios and 
woricflows, one can perform a second iteration through the 
65 identificarion process. 

The following steps describe one technique for identify- 
ing Business Components, FIG. 43 illustrates this Business 
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Component Identifying Methodology 4300 including both 
Planning and Delivering stages 4304: 

1. Start with entity-centric Business Components. For 
example, the customer is a significant entity in most 
biisiness domains, therefore a Customer component 
may be included. A Customer Business Component 
would encapsulate everything an organization needs to 
know about its customers, including customer infor- 
mation (e.g., name, address, and telephone number), 
how to add new customers, a customer's buying habits 
(although this might belong in a Customer Account 
component), and rules for determining if a customer is 
preferred. Entities themselves can be physical or con- 
ceptual. For example, customers and products are 
physical — ^you can touch them. Orders, on the other 
hand, are conceptual. An order represents a specific 
customer's demand for a product. You cannot touch 
that demand. 

2. Look for process-centric Business Components next. 
Generally speaking, a process-centric Business Com- 
ponent controls the flow of a business process. For 
example, in the utility industry, a Billing component 
would process customer, product, pricing, and usage 
information into a biU. Sometimes one wiU find an 
entity associated with the process — in this case, a bill 
or invoice — but another option is to model this entity as 
a separate, entity-centric Business Component, thus 
decoupling it from the process. 

What's the best way to identify the re^onsibilities of a 
business component? 

Review the business capabilities, business processes, 
business practices, scenarios, workflows, and other require- 
ments. Look for behaviors that will be supported by the 
application. In other words, what are the business functions 
that will be performed by the system? Assign them as 
responsibiUties to the most appropriate component. If com- 
ponents were people and computers didn't exist, one might 
ask, "Who is responsible for this task?" In fact, sometimes 
it's helpful to assign component owners who speak up when 
they encounter a responsibility that should belong to their 
components — ^Hey, I should be re^onsible for that!" 

This section addresses several frequently asked questions 
that more broadly apply to the physical implementation of 
component- and object-based solutions. The answers are 
intended to increase the awareness of the reader. Most of 
them only scratch the surface of issues that are somewhat 
controversial within the component and object community. 

What is the role of components in net-centric computing? 

Physical components play a critical role in net-centric 
computing because they can be distributed, as encapsulated 
units of executable software, throughout a heterogeneous 
environment such as the Internet. They have the ability to 
make the Web more than a toy for retrieving and download- 
ing information. Robert Orfali, Dan Harkey, and Jeri 
Edwards, well-known experts in the field of component- and 
object-based development, wrote the following about dis- 
tributed objects (same as "distributed components" for the 
purpose of this discussion): 

The next-generation Web — in its Internet, intranet, and 
extranet incarnations — must be able to deal with the com- 
plex requirements of multi-step business-to-business and 
consumer-to-business transactions. To do this, the Web must 
evolve into a full-blown client/server medium that can run 
your line-of -business applications (i.e., a delivery vehicle 
for business transaction processing) ... To move to the next 
step, the Web needs distributed objects. 

What's the difference between components and objects? 
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From a logical perspective, components and objects are 
the same. Tliey both model concepts from a particular 
domain, and they both encapsulate information and behav- 
ior. On this level, good component models and good object 

5 models share the same characteristics: high cohesion, low 
coupling, reusability, well defined services, and more. One 
might argue that granularity is a key difference. After afl, for 
an object-oriented design, components are made up of 
objects. This may be true, but in reality both of them come 

10 in all sizes, thus making this difference rather insignificant. 
From a physical perspective, components and objects arc 
similar, but different. The key difference relates to the 
different ways in which they are implemented. As long as a 
component's interfaces comply with an accepted standard 

15 like COM, JavaBeans, or CORBA, its internal workings can 
be implemented using any technology (e.g., Java, A^sual 
Basic, Smalltalk, C, or even COBOL). The internal work- 
ings of an object, on the other hand, can only be imple- 
mented using object technology. For the same reason (i.c., 

20 standard interfaces), it is possible to request a component's 
services from any platform. That's not true of objects, unless 
they are wrapped with interfaces that comply with the 
accepted standards, which would make them distributed 
objects (ie., components) instead. 

25 Robert Orfali, Dan Haikey, and Jeri Edwards also wrote 
the book The Essential Distributed Objects Survival Guide 
(1996). Chapter 2, "From Distributed Objects to Smart 
Component," is an excellent source of information about 
objects, components, and the differences between them. 

30 They say the following about physical components: 

A component is an object that's not bound to a particular 
program, computer language, or implementation . . . They 
are the optimal building blocks for creating the next gen- 
eration of distributed systems . . . Components are standa- 

35 lone objects that can plug-and-play across networks, 
applications, languages, tools, and operating systems. Dis- 
tributed objects are, by definition, components . . . Unlike 
traditional objects, components can interoperate across 
languages, tools, operating systems, and networks. But 

40 components are also object-like in the sense that they 
support encapsulation, inheritance, and polymorphism. 
What is a component model? 

This is a common point of confusion. From a logical 
perspective, the term "component model" is frequently used 
45 to refer to a Business Component Model in the same way 
that "object model" is used to refer to a business object 
model. 

From a physical perspective, a component model (or a 
component object model) defines a set of conventions that 

50 provides a standard way to develop and use physical 
components, including how to define properties, events, 
behaviors, etc. It also includes the standard structure of a 
component's interfaces, the mechanism by which a compo- 
nent interacts with other components, patterns for asking a 

55 component about its features, a means for browsing active 
components, and more. Some of the existing component 
models are COM, JavaBeans, and CORBA. 
Example: A Grocery Store 
A grocery store chain is creating an enterprise-wide 

60 Business Component model Currently the individual stores 
do not record specific customer information. 

Consequently, a model based on today's reqtiirements 
would not retain customer information. 

However, they are looking into preferred customer cards, 

65 Furthermore, while analyzing the industry, the project team 
reads about a competitor with a pharmacy and video rental 
service. In both cases, customer information becomes criti- 
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cal. So the project team creates scenarios describing how 
they would use customer information to support these 
requirements. They create one Business Component Model 
that supports both today's and tomorrow's view of the 
customer. 5 

In the near future, when the chain adopts preferred 
customer cards, and in the more distant future, if they decide 
to add a pharmacy or video rental service, the Business 
Component design for their current application will provide 
a solid foundation for the future requirement of tracking lo 
customer information. If they weren't using Business 
Components, they would not have a model that maps to their 
business domain, and introducing new requirements would 
require more abrupt changes. 

Example: Inventory Management 15 

A telecommunications company in the paging biisiness 
sells and leases pagers and services. One part of the com- 
pany is installing an inventory management system for 
tracking pagers, while another pari of the company is trying 
to determine how-to track the frequencies that arc owned and 20 
leased by the company. What does this company mean by 
inventory? Does it simply mean knowing what items are in 
a warehouse? 

When the company thinks abstractly about the concept of 
inventory, they discover that it's all about managing any- 25 
thing of value. When they look at what they have in 
inventory, they discover that it is countable, reservable, and 
has a cost associated with it. Inventory does not require 
specific knowledge of the use of an item in inventory; that 
tmowledge can be put into another component, such as Item. 30 
If inventory does not need to know the specifics about its 
use, then it could apply its ability to count, reserve, and value 
anything it is associated with. Inventory could be used to 
manage a variety of things: conference rooms, fixed assets, 
work in process, finished goods, and leased frequencies. 35 

So one can start out building an inventory management 
application and then build the ready-to-reuse Inventory 
component which, without modification, can support many 
other uses. In this way one can imload the concept of 
inventory so that it can be reused outside the context it was 40 
initially planned for. 

This section highlights key messages for project manage- 
ment. The Management Lessons discuss these points further. 
Manage Expectations-component Technology is Not a Sil- 
ver Bullet 45 

Components promise to enhance the ability lo quickly 
build robust systems through the use of reusable pre-built 
software components. Properly leveraged, components can 
provide the foundation upon which one meet and exceed the 
demands of a global marketplace which increasingly uses 50 
technology as a primary competitive advantage. Like object 
technology before, components are often portrayed as the 
magic silver bullet to slay the ills of software technology. 

Yet, the silver bullet mentality inevitably leads to unrea- 
sonable expectations. Intense media attention fuels these 5S 
expectations. For example, components are often compared 
to Lego blocks that are simply plugged together to form 
complex systems. Experience has shown, however, that 
component technology is not that simple and thatpayofiEs are 
primarily in the long term. There are several factors impede 60 
short-term payoffs. 

Most important, demand exceeds supply for professionals 
with component and object-oriented skills. Thus, many 
initial projects incur start-up costs related to recruiting, 
training, and learning curve. Furthermore, after receiving 65 
investment in training, individuals find themselves in 
demand, becoming higher risk to leave the organization. 
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Another unreasonable expectation is the belief that com- 
ponents may provide immediate software reuse. Experience 
has shown that reuse is not automatically attained; it is 
necessary to establish a disciplined approach to reuse and 
create a development cultiue that embraces reuse. 

A client's view of component technology may vary 
depending on their previous experiences. Client's with no 
component or object experiences may have the most unre- 
alistic expectations for what the technology can delivery. In 
contrast, clients that have attempted object-oriented appli- 
cations and failed may understand that components are not 
the "silver bullet'* that many have promised. In fact, these 
clients may require additional evidence of the viability of a 
component approach. For these clients, a component 
approach can be very appealing since a component-based 
architecture can combine both traditional and object tech- 
nologies. And lastly, there is the third category of clients that 
have achieved some measure of success with object tech- 
nology and view component technology as the natural 
evolution towards the goals that are only partially delivered 
by object technology alone. 

Component-based Development's Focus on the Long-Term 
is Usually a Good Tradeoff 

Component-based development is also inherently biased 
towards the long-term. For example, the development pro- 
cess strives for a higher degree of quality and reuse, incor- 
porating iteration between design and code to support refine- 
ment. Striving for this higher design quality may almost 
always, by definition, cost more up front. Despite these 
initial costs, component-based development's focus on the 
long-term makes economic sense. Experience has shown 
that 60-^% of development costs are in maintenance. 
Recruit a Project Champion or Sponsor with a Long-term 
Focus 

To ensure that short-term concerns do not outweigh the 
potential benefits, project management should maintain a 
realistic view of the benefits and risks of components. Thus, 
recruiting a projea diampion or sponsor with a balanced, 
long-term view is a key to success. 
Business Benefits Must Support Adoption of Component 
Technology 

Establish Clear Goals for a Component-based Project 

Component technologists sometimes promote component 
development for its own sake, without regard for the busi- 
ness benefits. However, rarely may management justify 
something they do not understand. Component technology 
introduces a daunting array of new terminology. 
Furthermore, if a pilot component project is latmched with 
unclear goals or mission, the significant short-term costs and 
challenges may inevitably undermine the commitment to 
components. 

Thus, component technology must be justified in business 
rather than technology terms. In many cases, a traditional 
client/server solution can deliver the benefits. This proves 
especially true for short-lived, simple, or moderately com- 
plex applications. On the other hand, component technology 
may benefit applications with characteristics such as: 

a long maintenance life 

complex processing or significant asynchronous logic 

complex data relationships 

very dynamic business requirements 

multiple access diaimels 

legacy evolution or replacement 

functionality common across multiple applications 
Firm Clients Have Achieved Business Benefits 

The number of engagements that have employed compo- 
nent and object technologies has continued to grow over the 
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last few years. These engagements have shown that object development, and increased effort for component and 

and component-based approaches can lead to significant assembly testing. However, once core, reusable objects in 

business benefits. the domain model and application firamcwoik stabilized, 

Reduces Maintenance Costs system testing the functionality and performance was much 

Properly designed component-based systems should 5 easier. For example, since less code and data knowledge was 

reduce maintenance costs. Encapsulating implementation replicated throughout the system, global changes could often 

details and data make a system more resilient to changes in ^.y making a change in one place, 

the business or underlying technology. Furthermore, design Component Technology May Help Improve Communica- 

decisions mtist rigorously consider what is likely to change, Users 

Susceptible points should be hidden behind an abstract, lo The close tie that component and object modelmg enables 

public interface that decouples their potential changes from ^^^^ solution and business process may 

impacting other components. ^^^P software analysts and users or business analysts to 

Component Reuse Reduces Development Time understand each other, reducing errors in communi- 

Components arc more easily reused because they provide cations. This represents a significant opportunity, because 

weUndefined interfaces and can often be used through visual 15 misunderstanding user requirements has been proven to be 

development tools. This make it more straightforward to cosUy type of mistake m systems development A 

develop components for one project and share them across component model further improves the understanding of the 

other projects. Furthermore, components can be designed so software design by providing a larger-grained model that is 

that their properties can be tailored to meet varying require- easier to digest. 

ments. Once a reusable base of components has been 20 ^^^^V' communication with users is often improved by 

estabhshed, the development time for subsequent projects ^sing scenarios which convey requirements through familiar 

can be reduced. business situations. 

In one utOity company they saw significant gains in the Multiple Access Channels 

reuse of components across initiatives. Rather than copying Component ardiitectures are inherently service-oriented, 

and tailoring source code for new initiatives they were able 25 Components provide their services through interfaces which 

to assemble apphcations from already created components. consist of operations. Because components are independent 

Another engagement estimated that new system develop- P^^^^ ^f software they can be reused by any number of 

ment was reduced 25% once the first application was applicaUons. Thus, component-based architectures are well 

released and a core set of components was established. Even suited to environments that need to provide multiple apph- 

though the engagement ultimately realized the benefits of 30 cation "personalities" or access channels. New personalities 

reuse, the cUent still had the expectation that reusable ^an be provided by creating a new user interface layer that 

components would save time and money for the first project. f^® ejdsting business components. 

To manage this expectation, the project team needed to Managing Risk is Key 

re-emphasize that component-based development requires Component technology is still high risk, because it may 

an initial investment. 35 

Leverage Existing Technology Investments have a pervasive impact on the overall development 

Many clients have existing technology assets that would approach 

require significant investments to replace. Components can require immature technology or tools 

enable these legacy systems to be wrapped with component implicitly involve complex functional requirements 

interfaces so that new applications can easily interact with 40 Component-Based Development is not only New Tech- 

them. Later, these legacy applications could be replaced nology; it is a New Approach to Software Engineering 

without changes to the new applications. Component-based development should not be understood 

Shields Complexity and Supports Re-engineered Processes as just a tedinology decision; rather, it is a new approach for 

Objects Raise the Level of Abstraction in the Software software engineering. Thus, it affects almost all aspects of 

Solution 45 development including methodology, tools, organization, 

Object development enables closer integration between and architecture approaches. This broad impact creates 

developing applications and rcengineering business pro- multiple learning curves, complicating the migration of an 

cesses. The first object-oriented language, Simula, was organization. Finding available skills is also difficult, 

invented to enable simulation. It and other object develop- because demand currently outweighs supply, 

ment environments provide capabihties that raise the level 50 Component-based systems may also require immature 

of abstraction of the software. That is, object-oriented Ian- technology or tools. Many of the core development tools 

guages and design tediniques enable writing software in such as the programming language and environments for 

terms closer to the real-world business rather than the C++, Visual Basic, Java and Smalltalk are actually very 

computer. robust. However, some of the ancillary tools such as the 

Enables Improved Usability ss CASE tools and web development tools or technology 

Object-oriented technology can support improved usabil- architecture components such as messaging middleware 

ity in two ways. First, objects messaging each other lends may not be as mature. Thus, the team may face a choice of 

itself to simplified programming of advanced, direct managing some risk exposure with a tool or library that 

manipulation or multi-media interfaces. Second, an object simphfies development, or avoiding this tool risk but facing 

metaphor for designing the user interface may be a more 60 a more complex development challenge, 

desirable interaction style for some types of users such as Another, more subtle source of risk is the inherent func- 

knowledge workers needing flexible navigation. tional complexity of applications often chosen for 

Reduces System Test Complexity and Cost component-based projects. Component technology's tech- 

In a few different instances, the object-oriented develop- nical characteristics enable dynamic, functionally complex 

ment approach has significantly reduced system test com- 65 systems. For example, business rcengineering can capitalize 

plexity. In all these cases the projects fell behind schedule on the inherent flexibility of component-based systems, 

due to learning curve, the complexity of custom architecture However, reengjneering creates more dynamic functional 
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requirements, thereby increasing risk. Not to mention that 
biisiness reengineering is itself a risky venture. 

Thus, proactive risk management is an essential practice 
in development. Traditional risk management techniques 
apply to component-based projects. For example, a "top ten" 
risk list can help focus management attention. This risk 
focus must then influence the development tasks carried out 
by the team early in the project to ensure risks are addressed 
in a timely fashion. 

Architecture is Essential to Delivering the Benefits 
Component Technology Enables Application Frameworks 

Component-based systems extend the notion of architec- 
ture beyond that in a traditional system. Much of the power 
of cjomponent-based systems is the ability to leverage appli- 
cation frameworks. Frameworks are somewhat analogous to 
program shells found in a traditional environment such as 
the INSTALL/1 online system with components like MES 
and CCR However, this is only an approximate analogy. An 
application framework goes beyond traditional application 
architectures to provide a greater degree of default behavior 
and flow of control in a skeleton of the application. 

For example, traditional program shells rely heavily on 
cut-and-paste techniques to achieve reuse. Hiis places a 
heavier burden on the developer and exposes the structure of 
the application. With an application framework, object- 
oriented capabilities minimize or eliminate the need for 
cut-and-paste reuse. A well-designed framework reduces the 
burden on application developers by providing an architec- 
ture environment that effectively says, "Don't call us, we'll 
call you." 

There are many frameworks within the Java programming 
environment. For example, Java Security, a very important 
topic in new netcentric architectures, provides a Java Secu- 
rity Framework. This is a plug and play framework that 
allows developers the option of plugging in a security 
provider of their choice (DES, RSA, etc) or developing a 
custom security solution that can be called by security 
cUents. To create a new security provider, the developer 
must only implement the required interfaces for the frame- 
work and provide a well-known name. Once these require- 
ments are met, the component can be plugged into the 
framework. 

Component -based Systems are Distinguished by a Business 
Component Model 

The Presence of a Reusable Business Component Model is 
a Key Characteristic 

A component-based software archilecmre may have a 
domain component model shared by the application pro- 
cesses. The component model contains the core business 
components that represent the business directly in software. 
These components perform behaviors upon request by 
windows, reports, or batch process control objects. 

The presence of a component model distinguishes 
component-based systems from procediiral, client/server 
systems. In a procedural approach, there is no shared busi- 
ness component model. This typically requires, for example, 
programs to pass data to each other in a context record. Thus, 
any changes to the data may affect many programs. The 
extent of business logic reuse is also usually less with the 
procedural approach. 

The presence of a business component model also distin- 
guishes a component-based architecture from that produced 
by componentware tools. Specifically, many traditional and 
even component-based tools provide data-aware controls 
that tie the user interface directly to the database. This is 
indeed a powerful technique to rapidly build simpler, less 
strategic applications. However, it suffers from "a lack of 
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smaller-grained business reuse and increased coupling 
between presentation and data. This may increase mainte- 
nance costs and miss opportunities to flexibly model com- 
plex bxisiness processes, as can be done with a component 

s model. On the other hand, producing a reusable component 
model requires a higher level of abstraction and is therefore 
a more difiGcult approach. 
Component Systems are Based on Standards 
Component-based systems arc also usually distinguished 

10 by their use of one or more of the leading component 
standards, i.e. CORBA, DCOM, or JavaBeans. These stan- 
dards define the mechanisms that business components may 
use to communicate with cadi other. However, a system 
docs not necessarily have to use one of these technologies to 

15 be considered component-based. The most important criteria 
is that the application is made up of reusable, service - 
oriented building blocks that encapsulate their functionality. 
Component-based Systems Can Incorporate a Variety of 
Technologies 

20 CUents Can Select the Most impropriate Mix of Technolo- 
gies 

Just as none of a user's client experience with objects has 
involved migration to a completely pure object solution, 
components may involve a variety of technologies. This is 

25 even more true for component-based systems since they 
provide the ability to integrate different technologies 
through well-defined interfaces. The ease of integration is 
very appealing to cKents since it allows them to maintain 
their existing technology investments, leverage their exist- 

30 ing skills, and select a mix of technologies that best fit their 
tolerance for risk. 

More Diverse Skills May be Required 

Because components can be implemented in a variety of 
programming languages on a number of platforms, it is often 

35 necessary to have competencies in a nimiber of technolo- 
gies. For example, one client used Visual Basic, Smalltalk, 
C++, and COBOL for different layers of the system. The 
increasing number of technology combinations also 
increases the complexity associated with development 

40 activities such as testing, debugging, and configuration 
management. 

Component Can Wrap Procedural Applications 
Wrapping is a technique to integrate traditional system 

components. It applies to both the application and system 
45 levels. For example, a component can provide a public 

interface, encapsulating a legacy application. 
Wrapping can be effectively applied to integrate a legacy 

billing system with a large, object-oriented customer care 

system, 

50 At the architecture level, wrappers often provide database 
interface objects to shield the application from the database 
vendor. 

Architecture Development Must Start Early 

A Tfension Exists Between Scenarios and Frameworks 

55 As with client/server, ardiitecture work must start early. 
As noted above, this is particularly challenging because of 
the level of application reuse in a well-designed application 
framework and domain component model. Because of this 
reuse, the framework must be heavily driven by application 

60 requirements, or scenarios. Yet, the architecture team must 
stay one step ahead of application development teams to 
ensure that the architecture and component model are ready 
in time to be reused. Hius, a difficult tension exists between 
scenarios and frameworks. 

65 The tension between scenarios and frameworks can be 
simplified to the extent that third-party or standard archi- 
tectures such as Eagle can be leveraged. In any case, the 
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following gxiidelines should be considered, particularly for Estimating and Planning Present New Management Chal- 

custom ardiitectures: lenges 

Hie architecture should be defined and prototyped, if Projects Should Albw Time for Start-up Costs and Contin- 

necessary, early in the preliminary design gencies 
The architecture should be complete -at the very least, the 5 There is still not enough experience with component 
development architecture and overall framework, prior technology to support rigorous, detailed metrics. One rea- 
to developers actually coding; the design must be in sonable checkpoint for estimating an initial project is to use 
place earlier when functional developers start detailed traditional techniques, and then add time to adjust for 
design; private architecture aspects may be deferred contingency and start-up costs such as training, learning 
Time must be planned for architecture support based upon lo curve, and architecture development Early client engage- 
unforeseen scenarios, performance tuning, documenta- ments have demonstrated that an initial project may almost 
tion and developer mentoring always be more expensive due to these start-up costs. 
Developing a custom application framework should be Yet, care should be exercised in applying traditional 
estimated as a set of tasks in addition to much of the estimating metrics. For example, traditional metrics often 
traditional technology architecture development 15 use number of days per window or report. Component-based 
New Roles and Organization Strategies must be Introduced development can result in significantly different window 
Component Projects Require Modeling Skills counts for similar functionality. 

Most traditional engagements divide roles into two basic In addition, the fixed versus variable nature of costs 

categories, functional and technical, or architecture. should be considered. Start-up costs are often not simply a 

Component-based development introduces a third dimen- 20 variable percentage of the project size, because roughly the 

sion by requiring an extensive modeling role. Early expe- same architecture components may be required independent 

rience has shown that the capability to draw abstractions in of size. Thus, anecdotal evidence suggests that the start-up 

modeling a business problem or application framework is a costs usually have a greater effect on a small project, 

unique skill set distinct ftom purely technical or functional Development Requires a Mix of Waterfall and Iteration 

skills. 25 Systems development traditionally relies on a waterfall 

Managing the Domain Component Model Requires New model. This approach manages development in sequential 

Organization Approaches phases of activity such as analysis, design, code, and test. 

In addition, the extensive reuse of a core business com- The waterfall provides control and discipline to 

ponent model requires an organization structure that man- development, particularly critical for large, mission-critical 

ages it as a shared resource. This creates a tension between 30 efforts. 

the needs to support consistent reuse of core components, On the other hand, iteration enables proving out design 

and the desire to solve a business problem firont-to-back. assumptions in code early in the process, and testing the 

Experience has shown this often requires some form of validity of code before proceeding on a wide scale. The 

matrix organization, combining vertical-based leadership information and learning gained from iteration are especially 

along the lines of business functions, and horizontal-based 35 important for component-based development, because it is 

leadership along the lines of architecture layers. so new. As component-based architecture and methodolo- 

Leveraging Expert Mentors and Time are Key to Scaling the gies mature, the need to iterate may be reduced 

Learning Curve Significant Plarming and Status Monitoring is Necessary to 

The Learning Curve is Greater, because it has Multiple Manage Iteration 

Dimensions 40 However, managing iteration on a large scale is difficult. 

Component-based development involves a longer leam- The team can easily slip into hacking, in which design is 

ing curve than comparable software technologies, because it simply sk^ped before coding. Or, a leam may use iteration 

has multiple dimensions. Component technology skills as an excuse to not exercise due diligence in completing 

cover a wide range of competencies — ^from modeling and tasks. Thus, a merging of waterfall and iterative principles is 

design skills to detailed programming syntax. Yet, a user 45 beneficial. Yet, striking a compromise between waterfall and 

may have good success with people scaling the learning iteration is not easy. Thus, significant effort must be invested 

curve in a reasonable amount of time. for detailed workplanning and status monitoring. 

Programmers can expect to perform simple tasks in 2-4 Incremental Development May Help Manage Scope and 

weeks when an architecture is in place. More complete Risk 

implementation skills may require 8-24 weeks. Design 50 Incremental Development Partitions the System Roll-out 

skills also typically require the same amount of learning into Releases 

curve, 2-4 weeks for simple tasks and 8-24 weeks or Perhaps the most effective way to mitigate the risks of a 

slightly more for complex design problems. Usually pro- large project is to simply avoid being large. Incremental 

gramming should precede design experience, if possible, development addresses risk by reducing the necessary team 

Thus, leveraging experienced component and object tech- 55 size and scope. "Incremental" and "iterative" development 

nology skills is key to success. Even a few skilled compo- are often used interchangeably, but they are different 

nent developers can provide significant leverage to mentor approaches. 

and support an inexperienced development team. Experi- Incremental development partitions the system roll-out 
ence has shown that at least 20% of the development team into successive releases. For example, the initial release of 
should have component technology or process skills at the 60 a customer system might comprise order processing, fol- 
outset. This represents a minimal level for large engagement lowed by a subsequent release for billing, and a third release 
teams with projects of one year or more duration. Smaller for collections processing. Thus, incremental development 
teams or shorter duration projects may typically require adds new functionality, while iterative development con- 
more. It is also extremely important to have a significant tinuously refines existing functionality, 
percentage of the team with client/server skills, to reduce 65 Incremental development avoids the complexity of a big 
additional learning curves such as GUI design or client/ bang integration. Furthermore, although an incremental 
server architecture development. approach delivers less in eadi successive release, it can 
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deliver higher priority portions of the system much earlier On the other hand, excessive application tuning should 
than a traditional approach, thereby recognizing business not be done to the exclusion of following good design 
benefits in a shorter time frame. principles, especially if the components arc built using 
Despite these benefits, incremental development is not a object technology, Experience has shown that dramatic 
panacea. Many times a big bang conversion has proven 5 performance improvements can be made late in object- 
necessary, if the cost and risks of having parallel systems oriented development projects. Furthermore, following good 
and bridges, performing conversion, and rolling out training design principles actually better enables these tuning capa- 
are high. These costs must balance those introduced by the bilities. 

delayed delivery of business benefits and the risks implied However, if more traditional approaches are used to 

by increasing scope and team size. The urgency of the lO implement the components, then it may be more appropriate 

business and the desire to manage development size may ^ tune performance throughout the development Hfecycle. 

sometimes favor an incremental approach. Third-party Components Have Increasing Importance 

Commercially Available Methodologies Have a Narrow Tbi^d party components can play an important role in 

Focus software development. Today's development tools make it 

Most component-based methodologies focus primarily on 15 ^ incorporate off-the-shelf components and customize 

analysis and design techniques. For example, less guidance ^ project's specific requirements. Thus far, off-the- 

is available for configuration management or testing. Yet, shelf components have primarily consisted of user interface 

both of these aspects are more complex with component- or architecture components. One project bought third party 

based development, because of the greater level of granu- components for the user interface, device drivers, bar- 

larity of the software decomposition. Because the method- 20 coding, and database driyere. This project found that it saved 

ologies are generic, they also typically do not address a significant amount of time, especially in areas that required 

detailed architecture or design steps. specialized programming skills. Unlike architecture 

Configuration Management and Testing are More Complex components, it is not likely that third-party business com- 

As noted above, the increased granularity of a ponents may be available any time soon, 

component-based system and the variety of technologies 25 Staffing, Training and Skills DevelopmeDt 

associated with it complicate testing and configuration man- This chapter discusses management issues related to 

agement. A component-based system may often have more staffing, training, and skills development, 

than ten times as many components as a traditional system. Component-based Systems Require a Mix of Technical 

While component-based systems are more granular than Skills 

purely object-oriented systems, configuration management 30 Object Skills arc Common, but Not Required 

is not necessary less complex. While the use of components Components and objects are frequently considered to be 

allows objects to be packaged into more comprehensible equivalent technologies; however, diey are not one in the 

interfaces, it also increases the number of elements that need same. While object-oriented systems may be developed 

to be managed. Typically, the following entities may be ^ing object-oriented analysis, design, and programming, a 

tracked: 35 component-based system can be developed using a wide 

Methods variety of languages, including procedural ones. As a result, 

^^^^ the required depth of skills for a component-based project 

may depend on the blend of technologies used. For example, 

Packages (which are often aligned with components) project may require skills in COBOL, C++, and 

Components ^ Smalltalk, while another may use \^ual Basic exclusively. 

Configurations ^ Because many projects are building components with 

^plications objects, deep object-oriented skills may continue to be an 

Configuration management requires a comprehensive essential ingredient in the success of a project, 

approach of tools, procedures, and organization approaches. Competencies in Multiple Technologies May be Required 

Multiple levels of component ownership must be defined. 45 Since component technologies make it possible to inte- 

The higher level of reuse requires frequent roll-outs of S^te different platforms, languages, and other technologies, 

updated component versions. This also typically requires the is often necessary to develop a broad portfolio of skiUs on 

workplan and other status monitoring techniques to track ^ project. It is important to develop an early understanding 

dependencies between components at a much lower level of of different skills required and how they can be devel- 

detaiL 50 op®d and leveraged across a project. 

In addition, completing a set of processing requires many Leveraging Experienced Component Practitioners is Key 

software components working together. Thus, testing Leveraging experienced component technology skills is 

involves integrating many more components. The complex- to success. Even a few skilled component developers 

ity is magnified, because the integration work often cuts can provide significant leverage to mentor and support an 

across different developers. The testing strategy must gen- 5S inexperienced development team. 

erally include more testing phases, each specifying a lower At least 20% of the implementation team should have 

level of detail. Furthermore, automated regression testing component skills 

has proven essential to address the complexity of Integra- Small teams or short projects likely require more 

tion. Experience has shown that at least 20% of the develop- 

Address Performance Risks Early, but Defer Application 60 ment team should have object/component technology or 

Tuning process skills at the outset. These represent minimal levels 

Timing when to address performance has subtle com- for large engagement teams with projects of one year or 

plexities for a component-based system. Certainly, more duration. Smaller teams or shorter duration engage- 

componcnt-based development involves new technologies ments need a higher ratio of experienced component devel- 

that introduce performance risks. Prototyping architecture 65 opers. Furthermore, custom building the architecture from 

components should be initiated early to adequately address scratdi may generally demand even more and deeper skills, 

the performance risks. unless the team has exceptionally talented individuals. 
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extensive client/server experience, and ample time to scale Experience with client/server development and a technical 

the learning curve. orientation 

It is important to note that component technology skills Willingness and flexibility to leam new tcrminobgy, tools, 

cover a wide range of competencies — ^firom modelfiig and and techniques 

design skills to detailed programming syntax. Rarely may 5 Strong communication and people skills, 

one individual have the necessary expertise in all these Sound understanding of the system's development lifecycle 

areas. Thus, experience has shown that it is necessary to find and the risks at the various stages 

individuals that specialize in one of these areas to leverage Architecture Roles Require Diverse SldUs 

across a large team. The key is obtaining the right balance Comphcating the search for architecture skills is the need 

of technology and methodology skills. to find developers who also possess the necessary cojnmu- 

One Engagement Used a 1:1:1 Rule to Leverage Expertise nications and teamwork skills. The architecture team must 

One large engagement found the most effective leverag- be capable of both delivering an ^plication framework, and 

ing ratio was 1:1:1, comprising an experienced object giving people appropriate mentoring and support. Many 

specialist, an experienced programmer without object skills, technology architects are simply not well equipped to handle 

and an inexperienced person. Note that this 1/3 ratio rule the tutoring, coaching, and communications demands inher- 

only appHed to the team doing implementation. Thus, even ent in component-based development, 

though the total team size was about 200, only 40-50 were Avoid starting inexperienced people in architecture roles, 

doing hands-on implementation, implying the need for about There are simply too many skills to leam. Architects need to 

13-17 skilled people. have a deep knowledge of design patterns, programming 

Another engagement found the best mix to be one expe- languages, technical infrastructure, and methodologies. It is 

rienccd developer to every four or five new developers. This 20 better to start new developers in application development 

project had a well-defined architecture and used Visual roles where they may have the opportunity to view the 

Basic to develop components. The relatively short learning architecture as a consumer. This perspective may make them 

curve of Msual Basic allowed this project to further leverage more effective in future architecture roles, 

its experienced developers. While the dual role of building and supporting an archi- 

Exerdse Caution when Contracting External Component 25 tecture exists in a traditional client/server system, it may be 

Speciahsts moK pronounced with component technology. Component- 

In some cases, independent contractors have proven an j,^^^ systems require a higher degree of coordination by the 

effective solution for fiHmg gaps with specific niche skills. framework developers partty because more application 

Experience has shown however, these people may not be ^,^,1 inexperienced with the environment, 

busmess-oriented, adapt well to the stmcture of a large ^^^J ^^^^ ^ experienced team requires extensive 

engagement, nor have experience with mission-critical j- A v ^ ^ t 7 

devek)pmcnt coordination, because a greater level or consistency is 

Another problem has been having to fight object rehgion required. . , , . 

Developing with component technology demands more 

Managers must Adopt New techniques, yet Not Forget consistency, because an appUcation framework and business 

Fundamentals 35 or domain component model provide more reuse. In 

It's often said that, a good manager can manage anything. particular, much of the business logic may be shared by a 
Many management skills such as planning, monitoring common domain component model, viewed by many win- 
status, working with end-customer expectations, and man- dows. To strive for this greater level of reuse across many 
aging risk certainly apply to any domain. These blocking- business functions requires coordination among many 
and-tackhng aspects of management must not be forgotten 40 developers. The risk is that the components may not fit 
on a component-based development project. Managers may, together. ^ 
at tinies, be intimidated by component experts, and ignore This type of development approach requires a strong 
the basics of project management. architecture vision that is clearly communicated and sup- 
Managing Iteration is Difficult, but Possible ported through training, mentoring, and documentation. If a 

In particular, object industry and academic gurus fre- 45 strong vision does not exist, then the components may 

quently suggest that object development and iteration simply inevitably not fit together into a cohesive, integrated archi- 

cannotbemanaged. Their recommended approach is usually tecture. In addition, this strong vision must include an 

some form of time-boxing the development, simply declar- understanding of the business objectives and functions of the 

ing victory whenever time is up. However, this represents a system to be effective. 

very unappealing approach to promising delivery of busi- 50 Strong architecture direction must also be accompanied 
ness benefits to clients. Fortunately, experience has shown by a positive "bedside manner". Application window devel- 
that this does not have to be the case. Managing iteration, opers may often perceive a framework somewhat restrictive 
while certainly more difficult, is possible, of their creativity, too limiting, or burdensome, particularly 
However, software development managers must recog- when bugs hold up their delivery. It*s important for the 
nize that component technology has a pervasive impact on 55 frameworks developers to be service-oriented; and, to real- 
many aspects of the development process including ize that developing a reusable component is hard work and 
estimating, planning, methodology, and technology archi- requires iteration. 

tecture. For example, iteration impacts many of the standard Do Not Organize AH the Component Skills on the Archi- 

rules-of-thumb for work completion. And the extensive tecture Team 

reuse of a common business component model requires 60 Because of the significant technical challenges often 

more sophisticated organization strategies. faced, a team may be tempted to staff all the experienced 

Managers Must Invest Hme in Training component developers on an architecture frameworks team. 

Thus, successful managers must be willing to invest the This strategy makes some sense. However, it should not be 

time to learn new terminology and techniques to adapt to followed to the exclusion of leveraging the application or 

these changes. Traits common to those who have success- 65 component modeling development team. Developing the 

fiilly scaled the component management learning curve functional business logic requires component development 

include: and methodology skills, as well. 
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Staff an Engagement Team with a Mix of Backgrounds 

Staffing an engagement with deep technical skills is 
clearly a challenge. However, the engagement team should 
not overlook the importance of functional skills. Experience 
has shown that technical backgrounds may sometimes be 
over-emphasized to the detriment of functional expertise. 

It is important to remember that many roles on the team 
are more demanding functionally than technically. Inter- 
viewing users, analyzing business processes, and designing 
the user interface all do not require extensive technical 
training. Moreover, not adequately understanding and ana- 
lyzing the functional requirements are the most expensive 
mistakes. Research has shown that 70-80% of a system's 
mistakes result from misunderstood requirements. 
Component Technology Involves Multiple Learning Curves 
A component approach affects almost all aspects of the 
development lifecycle. For this reason the component team- 
ing curve cannot be equated with a programming learning 
curve such as *C'. There are multiple, distinct learning 
curves that affect individuals at many different levels in the 
organization: 

Component and object-oriented concepts and terminology 
Object analysis and design 
Programming language 

Programming enviroiunent and other development tools 

(e.g., browsers, debuggers, user interface tools) 
New architectures — such as how to use the project- 
specific application framework 
Management — such as estimating and planning for work, 

and managing iteration and prototyping 
Educating management about the multiple learning 
curves helps manage expectations. It's also important to 
avoid equating experience with pure elapsed time. For 
example, a person may be in the implementation phase 
doing things unrelated to building their component skills 
such as creating test conditions. 

Component Skills May Take Longer to Transition to the 
Client 

As a result of the many learning curves, it can take longer 
to successfully transition skills to the client. It is essential to 
have chent participation in aU areas of the project to ensure 
the transfer of skills. One of the most effective approaches 
is to have client personnel pair up with more experienced 
developers. Of course, this may be more expensive and may 
required buy-in from management. 

The Rate at Which Individuals Scale the Learning Curve 
Varies Widely 

Experience has shown that individuals scale the learning 
curve at very different rates. A user may have good success 
with individuals becoming productive in a reasonable 
amount of time. In some cases, people have learned 
extremely fast; on the other hand, a few have had consid- 
erable difficulty. 

A useful model of the expected learning curve is outlined 
by Goldberg & Rubin [3]. These results are based on their 
extensive experience training personnel, primarily in the 
Smalltalk environment. Three primary levels of proficiency 
include; 

Basic — capable of doing basic assignments with adequate 
supervision, usually attained after formal training and 
some experience with simple assignments 

Functional — capable of doing most assignments with a 
predictable level of productivity and minimal supervi- 
sion 

Advanced — an expert resource capable of solving very 
difficult or imusual problems 
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They distinguish the learning curve in four different skill 
areas as shown below, measured in months: 



5 



10 



Category 


Ba 


sic 


Func 


Adv 


Analysis eiad Design 


4 


wks 


6-8 moa. 


18-24 mos 


[a^l&mentation 




wks 


5-6 mos 


18-24 mos 


Frameworks Design 


16 


wks 


12^24 mos 


24-48 mos 


Management 


3-4 


wks 


12-18 mos 


24-36 mos 



The above results are reasonably consistent with a user's 
experience on client engagements. Some experience sug- 
gests that most firm personnel, on average, reach proficiency 

15 levels slightly faster than the above figures. However, a user 
may experience a much larger deviation, both positive and 
negative, than that reported above. 

For example, some talented individuals reached a func- 
tionally competent level in implementation skills in as little 

20 as 8 or 10 weeks, less than half that suggested above. On the 
other hand, about 10-15% of individuals did not ever reach 
this level of expertise in a reasonable amount of time. 
Early Experience has Identified Key Predictors of Success 
As noted above, a user may experience a reasonable 

25 degree of success in training personnel on engagements. 
Unfortimately, some clients have not been as successful. 

Key predictors of success can be drawn ffom this expe- 
rience and others. It is important to recognize that the list 
below is drawn firom a very small experience base. As one's 

30 experience grows, the list of traits may be refined with- 
hopefully-more objective measurability. This may be key to 
helping both a user and clients to be more successful with 
components. 

Ability to Deal with Change 

35 Component-based development requires a high degree of 
change. Firm personnel deal with change their entire career. 
Often, client personnel may not be as adaptive. They may 
have worked with the same structured methodology and 
COBOL for 5 or 10 years. To change their entire process can 

40 be a big culture shift. Individuals must have the right attitude 
and interpersonal flexibility to change. This factor may help 
explain why less experienced people have often scaled the 
learning curve faster than more seasoned developers. 
Yet, the simple fact that someone has deep COBOL 

45 experience does not mean that they may fail. There have 
been several examples of people on engagements who 
successfully made the transition from COBOL to Smalltalk, 
including architecture roles. However, all of these individu- 
als were highly motivated with an open mind to change. 

50 On the other hand, migrating to C4--1- may be a consider- 
able challenge for people who do not have experience with 
a pointer-based language. That is, C++ projects should favor 
staffing people who have minimally programmed in lan- 
guages such as C or assembly language. 

55 Quick Study 

Component technology involves multiple learning 
curves-people may need to learn fast. They must be moti- 
vated self-starters, capable of learning quickly on their own, 
and willing to read and perform supplemental tasks to 

60 improve their competencies. 
Communications Skills 

Component-based projects are very social endeavors. 
Because any given business function requires several col- 
laborating components, developers also have to collaborate 

65 with one another. To ensiire that components integrate 
smoothly, and to achieve the desired reuse, a high degree of 
communications and teamwork is necessary. This is signifi- 
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cantly different than many traditional systems where a after initial skills are developed. This generally requires a 

system is decomposed into larger, monolithic modules. fair degree of commitment from experienced frameworks 

These modules are typically developed front-to-back by developers to provide mentoring. 

each developer in relative isolation. A Formal Certification Process Supports On-going Skills 

Creativity— Experience with Custom Systems Development 5 Development 

Acomponeot-based development project requires creativ- Since component technology can result in many new 

ity. The overall atmosphere is usually very challenging with ^ competencies, an ongomg, comprehensive skills 

fewer, concrete rules. The answer to many analysis and ass^ment and certification process has proven benefid^^ 

design decisions is, "it depends^ Similarly, the development ^crfafi^aUon process defines areas of competence and then 

. , 1 *• J u • cntically eval^tes mdividuals capabihty and progression. 

W k ''^lo^Uon and browsing. lo ^^^^ ^^.^ and coding skilk to inclnde 

WorK litnic famiharity with portions of the architecture. Peoples* skills 

Individuals must be motivated to undertake personal ^^^^^ ^ compulsory design and code reviews. In 

trammg. There often is not enough tune to support all the ^q^^^ becomes a component-specific skflls evaluation, 

trammg needs dunng normal work hours for the system to ^ certification process helped to: 

meet a reasonable schedule. Thus, at times, individuals must 15 j^^^ rigorously identify and describe competencies of 

pursue personal study and experimentation after hours. This ^jj^j jg ^gally desired in terms of skills and compe- 

typc of commitment requires enthusiastic, hard-working tence; and, what habits should be discouraged and 

individuals. flagged as performance problems. 

Initial Training Requires Hands-on Case Studies to be jrack peoples' growth-it encourages improvement by . 

Effective 20 challenging people. 

Initial training requires significant upfront investment. Provide a more effective way lo assign appropriate roles 

Project Eagle achieved very good results with tiieir multi- to people and offer up the opportunity for people to 

week Eagle University. Unfortunately, this represents a grow into a more challenging role as quickly as they are 

larger amount of upfront time than many engagements can adequately prepared. 

reahstically support. In addition, timing may be difficult, 25 Support more effective communications of what 

because often project team members may roil on the project resources had which skills (e.g., through a wallchart) 

at different times. Simimary 

Thus, many engagements may need a more flexible model Component-based development requires more time to 
with training time staggered in smaller chunks. For example, scale the learning curve, because it has multiple dimensions, 
the training may be accomplished through some combina- 30 Component technology skills cover a wide-range of com- 
tion of formal classroom training done in waves, self -study, petencies including analysis, design, programming, and 
case study experience with mentoring, reading, and on-the- management. Thus, leveraging expert mentors and skflls, 
job training. The key point, however, is that a significant investing in adequate training, and enswing continued sup- 
commitment to training must be made-whether done upfront port are all key to success, 
or spread throughout the project. 35 Team Organizations and Roles 

There are several other lessons learned that can be drawn This chapter discusses the team organization and roles 

from the Eagle experience. Perhaps most important, training involved with component-based development, 

should be based on case studies. It should involve a signifi- Manage the Team Size with Care 

cant degree of learning-by-doing including both design and Team size should be managed carefully. Component- 
coding exercises. Examples can be taken from the actual 40 based development involves difficult coordination overhead, 
application to be buflt, thus reducing the perception of pure This stems from the higher degree of reuse and greater 
training investment. However, care must be taken to ensure modularity of the system. A greater number of common 
that day-to-day project demands do not detract from the components are reused across business functions. In 
training. For example: addition, components are smaller than traditional modules. 
Simple examples from wetL-known domains (e.g., check- 45 Thus, more work from multiple people must integrate 
book application) ensure that the application require- smoothly. This complicates increasing the team size, 
ments do not bog down the learning process. If aproject slips off-schedule, caution should be exercised 
People may need to be taken away from the project site, ^ l^^^ P^^P^^* fundamental law states: 
or firewalls created, to enable a total immersion envi- ^^^^ f ^P^^ ^ * V^'^. P^^J^^^ 
ronment ^ ^ underestimate the impact more people have on 

, coordination and communications. Start-up costs can also be 

Individuals should work m teams to sunulate the collabo- .j^^^^t. ^ew developers may have a leammg curve. 

ration necessary on an engagement. ^^^^ experienced developers must learn project-specific 

If real portions of tiie application are used, the team aspects such as the framework, business requirements, and 

should manage expectations so as not to confuse train- 55 team structure. These initial costs not only impact a new 

ing goals with producing deliverables. team member's productivity, they also reduce experU' avafl- 

Reuse should be taught and encouraged through exercises ability for mentoring others, 

that force the developer to browse. Manage Expectations Regarding Developer Productivity 

On-going Support is Necessary for Developers to Scale the Industry Gurus Have Created UnreaUstic Expectations for 

Learning Curve 60 the Required Team Size 

On-going support is necessary to help developers con- The need to manage team size must not create unrealistic 

tinue building skiUs. On-going training is important because expectations for developer productivity. High expectations 

the entire development lifecycle is affected, to some degree, have been fueled by many object industry e^qjcrts who 

by the shift to components. An individuals first few assign- recommend a dramatically smaller team. Many have sug- 

ments should be carefully planned to enable growing skills, 65 gested that as httie as 80-90% fewer people can accomplish 

and to identify people who demonstrate aptitude. Time must an equivalent amount of work as a traditional development 

also be allowed for scaling the productivity learning curve, team. 
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However, experience does not support these exaggerated 
claims. Initial cngagcmeats have incurred considerable start- 
up costs such as training, architecture development, and 
building reusable components. 

Some compelling evidence suggests object/component 5 
technology can improve productivity enough to reduce team 
size later in the software development lifecycle or for 
subsequent projects. Brooklyn Union Gas cut their mainte- 
nance staff in half and still accomplished as much or more 
work. Other firm experience has shown object technology 
reduced system test effort, enabling a smaller team. Large 
engagements have also realized benefits of reuse, signifi- 
cantly reducing development time for windows later in 
development. However, none of these cxperieoccs reported 
an order of magnitude reduction in team size. 
Use Components as Work Packages 
Components Can Define Work Packages 

Perhaps the most effective way to mitigate the risks of a 
large project is to simply avoid being large. Partitioning a 
project into smaller sub-systems is one way to reduce size. 
Component-based development is particularly well-suited to 20 
partitioning the development effort because the constituent 
components can map directly to team responsibilities. This 
simplifies division of responsibility and roles, because soft- 
ware and team organizations can mirror each other. 

For example, FIG. 44 shows a high level picture of 25 
application component interaction for an Order Entry sys- 
tem. The boxes represent the application components of an 
application being developed Orders are fulfilled by inter- 
action with the Product, Customer, and Warehouse Appli- 
cation Components. These software application components 3Q 
can then serve to define the structure of teams and their 
collaborations with each other. 

Keep in mind, however, the benefits of this partitioning 
approach may be influenced by the degree with which these 
components interact. Thus, determining the appropriate 35 
granularity of the components is a key, strategic design 
decision. 

Greater Specialization of Roles is Necessary 

IWo recent engagements involved very large teams, in 
one case peaking at over 200 people working with object- 40 
oriented technology. In both cases, the engagement teams 
leveraged expertise in a manner somewhat similar to a 
traditional engagement. There were, however, important 
differences in scaling object-oriented development to such a 
large size. 45 

One important distinction is the categories of expertise to 
be leveraged. For a traditional engagement, most developers 
tend to be divided in two basic categories — ^fiinctional or 
technical. These two dimensions represent the primary types 
of leveraged expertise. That is, guidance is provided by 50 
functional and technical experts. 

Component Development Requires Functional, Technical, 
and Modeling Competencies 

A component-based project adds a third dimension — 
modeling. The skill set to model and represent behaviors and 55 
relationships in components and objects is a distinct, com- 
plimentary skill set to functional and technical skills. Thus, 
most projects find that they need a third type of expert — e.g., 
a component/object modeling architect(s), to provide direc- 
tion. 60 
Four primary online development roles may be defined: 
window team members developed the window-specific 
functionality. Their role was biased towards consuming 
rather than providing common object behaviors, 
although there was some degree of the latter. 65 
object model team members developed complex behav- 
iors in the common object model; they also performed 
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quality and consistency reviews for object model 
behaviors implemented by window developers. 

frameworks team members developed the overall archi- 
tecture mechanisms, providing structure and default 
behavior for the entire application. 

server team members developed common data access and 
service routines on the server. 

Architecture roles must be defined to support this greater 
degree of specialization. One engagement used the follow- 
ing partitioning strategy: 

Functional architect-responsible for resolving decisions 
for what the system should do. This person is ideally a 
user with a solid understanding of systems, or a systems 
person with a good understanding of, and relationship 
with, the \isers. 

Technology architect-responsible for delivering the 
platform, systems software, and middleware infi'astruc- 
ture to support execution, development, and operations 
architectures. 

User interface architect-responsible for setting direction 
of the user interface metaphor, layout standards, and 
integrated performance support (IPS). 
Application frameworks architect-responsible for 
designing, delivering, and supporting the application 
framework that provides the overall structure, or 
template, of the application. 
Object model architect-responsible for identifying and 
resolving modehng issues necessary to achieve a high 
degree of business reuse and modeling consistency. 
Note that the last two roles are especially unique to 
object-oriented and component-based systems. This means 
these architects have a learning curve to simply understand 
what their role means in the organization. Furthermore, the 
architecture roles require the deepest technical skills and 
should be staffed with the more experienced resources on the 
project. 

One must be very careful in ensuring that application 
frameworks are not "over-architected". Experience has 
shown that many frameworks fall by the way-side for the 
simple reason that they were not built closely enough in 
conjunction with the application development. They become 
too theoretical; complicated and over-engineered making 
them performance bottlenecks and obstacles to simplifying 
the appUcation architecture. It has been found that frame- 
works should "fall out" of the application domain as can- 
didates become obvious. Experienced developers that work 
closely with the application can quickly identify repetitive 
constructs and abstract useful frameworks from this context. 
Data and Object Model Architects Mxist Clearly Define 
Their Roles 

One issue that must be resolved early on is the relation- 
ship between the role of the data architect and the object 
model architect In traditional development environments 
data architects produce deliverables such as Entity Relation- 
ship diagrams. Since an Object Model is a superset of an £/R 
diagram, it is important to avoid treating the two as separate 
entities because this can lead to development teams working 
from two separate scbemas. Viewing the object model as the 
object and data schema is very helpful in solving perfor- 
mance problems later and in promoting an overall under- 
standing of the information schema of the system. 

One strategy that has been shown to work is to include the 
senior data modelers in the object modeling team and give 
them appropriate object modeling training for their roles. 
This allows a natural migration of the object model to be the 
logical schema for the database model. However, this must 
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be carefully managed so that good object model principles 
are not violated by a strong-minded data modeler who has 
not transitioned through the paradigm shift. 
Greater Collaboration Between Roles is Necessary 

Another distinction is the necessary coordination of roles 5 
due to the impact reuse has on the organization. In a 
traditional architecture, modules tend to be larger front-to- 
back slices of functionality. Reuse is primarily confined to 
technical services. Thus, functional developers can work 
independently, relatively speaking. The greater degree of 
reuse in a component architecture, on the other hand, 
requires much more coordination of effort. 
The Organization Structure Must Enable Specialization and 
Collaboration 

Component development requires a more sophisticated 
organization structure to support the increased specialization 
and collaboration of roles. Specialization is generally more 
important because more is being custom created- and less of 
the answer is codified as a proven solution. As noted above, 
well-defined roles are also important to ensure reusable 
components fit together. ^ 

At the same time, the structure must enable adequate 
collaboration of team members. Too many specialists may 
result in an organization that requires extensive coordination 
to dehver anything — e g., a completed window. The orga- 
nization must then strike a balance between "vertical" ^ 
partitioning by function and "horizontal" partitioning by 
architecture layer. This is a classic management problem at 
an enterprise or project level. 

Vertical Partitioning by Business Function Better Supports 
Collaboration 

FIG. 45 illustrates a traditional organization structure 
including an activities component 4502, a credit/collections 
component 4504, a billing component 4506, and a finance 
component 4510. This traditional organization for most 
projects is vertically organized based upon business function 
with a technology architecture team. In this organization 
model, there would be one or more developers that are 
responsible for building a biisiness function end to end. This 
works weU for the following reasons: 

aligns well with the business process and software decom- ^ 
position 

enables clear work direction — i.e., complete a window or 

report, front-to-back 
ensures that complete fimctions work in an integrated, 

end-to-end fashion 
teams better align to application releases 
However, there are several potential shortcomings with 
this approach for an object-oriented system: 
may force developers to leam multiple aspects of the 50 

framework (e.g., user interface and persistence 

services) which does not enable as much speciahzation 

of skills 

does not easily support consistency and reuse of business 
logic 55 

does not readily enable cross-function leverage of exper- 
tise 

Horizontal Partitioning by Architecture Better Supports Spe- 
cialization 

Several object-oriented engagements have tried an alter- so 
native horizontal, or architecture-based, organization. FIG. 
46 provides an illustration of a horizontal organization 
model 4600. In this model, one or more developers are 
responsible for a horizontal layer of the system. Teams may 
be organized around layers such as technology architecture, 65 
frameworks, user interface, component/object model, or 
data access. 
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This approach offered the following advantages: 
aligned with the object architecture 
enabled cross-function consistency and reuse of business 
logic 

supported developing and leveraging speciaHzed exper- 
tise 

However, the following drawbacks were experienced: 
over-the-wall problems in coordinating hand-offs of work 

amongst multiple developers 
providing work direction to people became more compli- 
cated since they were poorly aligned with the business 
problem 

managing completion of business fiinctions becomes 
nearly impossible 
A Workcell Organization Combines the Two Approaches 

FIG. 47 ilhistrates a workcell organization approach 
including an activities component 470(2, a credit/collections 
component 4704, a billing component 4706, and a finance 
component 4710. This approach combines the two previous 
approaches into a workcell. Ihe primary orientation can be 
aligned either way, but a functional orientation seems more 
natural for a business application. A cell is comprised of a 
complete set of specialized skills such as functional analyst, 
object modeler, appHcation architect, and even user. Cross- 
cell architects then provide specialized direction for a par- 
ticular role. 

This approach, while adding complexity to the organiza- 
tion structure, has been used successfully on a number of 
engagements, and has been shown to combine the benefits of 
the two approaches. Of course, a drawback is simply an 
added level of organizational complexity — e.g., individuals 
at times taking direction from two different people. 
Additional Effort is Needed to Ensure Consistency Across 
Workcells 

Additional effort is needed to ensure that each workcell 
develops application components in a consistent manner. It 
is important to define development standards and entry and 
exit criteria for all workcells. In addition, it can be useful to 
have a single person or group perform design reviews across 
the project. 

A workceU's architect or frameworks developer can also 
help application developers better imderstand the architec- 
ture and use it consistently. Furthermore, the workcell 
architect serves as a good channel to feed new 
requirements — based on the application developers 
experiences — back to the architecture team. 
Management May Need to Plan for at Least One Major 
Re-organization 

The most effective approach depends on the team size, 
relative experience, and even the phase of the project. The 
dependence on development phase implies that management 
may need to plan for at least one reorganization. 
Unfortunately, re-organizations create significant team 
disruption, which must be considered. 
Workcell Organization May be Influenced by Other Factors 

Some additional guidelines include the following: 

Larger teams generally need to favor increased 
specialization, because they may almost always have a 
higher proportion of inexperienced developers. Thus, the 
specialized model supports developing areas of competency. 

Early in an engagement more speciaUzation may be 
required as an infrastructure of common components and 
frameworks is constructed. 

Once components are stable and integration of function- 
ality is more important, then a collaborative, functionally- 
aligned or workcell organization may make sense. 
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The higher degree of custom devebpmeat required in the 
architecture, the more specialization of skills is necessary; 
Likewise, the more stable the architecture, the less important 
is specialization in favor of supporting collaboratioa 

Complex, non-standard problems that cut across domains 
lend themselves to increased collaboration. On the other 
handy more standardized problems can be solved with the 
specialized model. This experience is also consistent with 
management research of macro-organizations for an enter- 
prise. 

Workcell alignment may be influenced by the needs of the 
client If the client^s objective is to develop a highly reusable 
business component model, then it may be appropriate to 
have a single team focused on developing the component 
model. On the hand, if the client is most concerned about 
delivering business functionality, workcells should be 
aUgned by business function. 
The Organization Must Support Informal Structures 

Whatever the formal organization, the project must enable 
extensive informal communications. Component develop- 
ment requires a tighter coupling between functional and 
technical design, because more commonality is incorporated 
into the architecture as common services. Thus, few impor- 
tant decisions can be made solely by one group within the 
project. 

One large engagement combined several different strate- 
gies to ensure effective communications across organiza- 
tional boundaries; 

cross-cell weekly integration meetings were used to dis- 
cuss and resolve low-level issues of global concern 
temporary, cross-cell teams were formed to address many 
special issues — e.g., integration with an external 
system, an approach to handle addresses, etc. 
temporary scout teams were formed to pilot the approach 
for a global change before rolling out to the entire 
team — e.g., the migration approach for moving sub- 
systems into system test. 
It's also important to consider the importance of informal 
sharing of information when many developers are undergo- 
ing training or there are global architecture changes under- 40 
way. Geographic splits of a team can cause special problems. 
Roles are Changed for Persoimel at Multiple Levels 

There often is not a direct mapping to the traditional roles 
that individuals expect. Analysts and Consultants may be 
given tasks with less creative freedom than they expect. For 45 
example, an Analyst role may involve less custom coding 
and more reusing, assembling, and testing of components. 
Design tasks for a new Consultant may also seem overly 
restrictive, because the challenge is to do things in a much 
more consistent, standard manner as dictated by the frame- 
work. 

On the other hand, because everything is often so new to 
the entire project team, in some ways everyone is starting 
together from scratch. Thus, in a few cases, very talented 
Analysts with prior component experience have assumed 
lead technical design roles. 

Traditional Hand-offs Between Designer and Coder are 
Problematic 

The way roles work together is also different. For 
example, because of the iteration and coupling required 
between design and code, hand-offs from designer to pro- 
grammer generally do not work well One scenario used to 
leverage skills involved a lead designer creating the design, 
prototyping the solution, and stubbing-out methods with 
comments. The details were then flushed out by a junior 
developer. Leveraging by review and mentoring has also 
been key. 
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Summary 

Crafting an organization structure for a component-based 
project involves balancing many complex factors. The most 
effective approach may depend upon the size and skill set of 
the team, the architecture structure and stability, and even 
the type of the application. Some additional considerations 
include: 

Regardless of the chosen organization, care must be taken 
to ensure walls do not build up between teams 

People's behavior may be influenced by the organization; 
that is, research has shown that the organization model 
may be reflected in the software architecture. For 
example, one engagement experience may shown that 
individuals may allocate behaviors to inappropriate 
components to avoid having to collaborate with other 
developers 

Workcells combine the benefits of horizontally and ver- 
tically aligned organization structures, and have been used 
successfully on a number of engagements. 
Planning and Managing Development 

This section discusses strategies for managing a 
component-based development process. IWo alternative 
development strategies are: 
Waterfall Approach 
Iterative Approach 

Much of the one's experience may be with large, mission- 
critical projects. Moreover, large projects introduce 
additional, inherent complexity. Hierefore, these issues may 
be discussed primarily from a large project perspective. 
A Tension Exists Between the Waterfall and Iterative Devel- 
opment Models 

The Waterfall is the Traditional Approach to Managing 
Software Development 

Systems development traditionally relies on a waterfall 
model. This approach manages development in sequential 
phases of activity such as analysis, design, code, and test. 
The waterfall model provides a controlled, orderly process 
for developing a system. Work is sequenced to ensure that 
the design addresses the correct requirements, implementa- 
tion is based on upfront design, and system testing verifies 
and validates thoroughly unit tested components. 

Despite these benefits, the waterfall model introduces 
potential problems. For example. 

Requirements may be difficult for the user to understand 
without prototyping the user interface or functionality 

The design team may not be prepared to specffy an 
effective design without gaining implementation expe- 
rience 

A team may not be positioned to generate reusable 
components for itself, unless a team works ahead to 
construct an architecture or component model during 
the design phase 
Iteration Helps a Team Address Risks and Gain Experience 

Because of the above shortcomings, much of the 00 and 
component community recommends some variation of itera- 
tive development, in which analysis, design, and coding 
activities overlap to some degree. A theme in these varia- 
tions is the need to address risk by proceeding further in 
development sooner. Both the gained information and expe- 
rience can influence the approach taken in the current phase. 

However, iteration also has drawbacks. The team may slip 
into hacking, by simply skipping design before coding. Or, 
a team may use iteration as an excuse to not exercise due 
diligence in completing tasks. Defining and estimating mile- 
stones is also hard. 



06/17/2004, EAST Version: 1.4.1 



us 6,636,242 B2 

159 160 

A Project Must Weigh the Tradeoff Between Waterfall and Iteration Does Not Scale Well Due to CommunicatioDS 

Iterative Models Overhead 

Hius, a tension exists. The waterfall promotes discipline Aside from these psychological considerations, large 

and control in the development process. In contrast, iteration projects introduce significant risks due to the complexity of 
proves out assumptions, gains advance experience, and 5 coordination. A large team has a much greater inertia, 

addresses risks. Balancing these conflicting goals is dif&cult because of the time delay and enors introduced in human 

on a large scale. communications. Any change takes much greater effort and 

Distinguish Between the Macro and Micro Process in the time to implement. Correspondingly, once made, changes 

Workplan ^ niore difficult to reverse. Greater reliance on documen- 

Both the waterfall and iteration have pros and cons. A ^^^^ ^ o^en necessary to avoid miscommunications. 

hybrid capitalizes on the advantages of both. If they are Many decisions must then be considered from the vantage 

merged, one or the other must inevitably dominate the point of their ease of communication. This complicates 

structure of the high-level project plan. That is, the plan must iteration. For example, if analysis, design, and code overlap 

start somewhere — either by defining iterations or waterfall- extensively, then by definition, requirements and design 

like phases of completion. change later in the process. Communicating wide-scale 

For example, definmg iterations of the system or sub- changes late in development can be inefficient, wreaking 

system would result in high-level project phases such as: havoc on existing code. Thus, iteration does not scale well 

J • to the macro level, because of communications overhead, 

lirst working version * 

refined working version 20 . "'s important to re-state however, that a pure waterfall 

. mtroduces many problems for component development due 

final, released workmg version intrinsic reuse and newness. Hius, many of the lessons 

In oontot a more traditional waterfall structure would below emphasize variations of iteration and how they can be 

result m high-level project phases such as: ^^^^^ ^ ^^j^^^l approach. 

requirements definition ^ Incremental Development May Help Manage Scope and 

preliminary design Risk 

detailed design and/or coding Incremental Development Partitions the System Roll-out 

testing into Releases 

AmaCTo plan reflects the high-level development phases Perhaps the most effective way to mitigate the risks of a 
The micro plan shows the tasks of a specific phase or team. 30 jarge project is to simply avoid being large. Incremental 

Distinguishing between a macro and a micro process development addresses risk by reducing the necessary team 

provides a practical compromise. The pure, traditional size and scope. "Incremental** and "iterative*' development 

waterfall has no distinction. There, the entire workplan and are often used interchangeably, but they are different 

accompanying development approach sequence analyzing approaches. 

everything, then designing everything, then coding and 35 incremental development partitions the system roU-out 

testmg everythmg, with no overlap. The same uniformity successive releases. For example, the initial release of 

between macro and micro processes apphes to a pure ^ customer system might comprise order processing, fol- 

iteraUve model. In this case, the workplan reflects multiple j^^^^ ^ ^ subsequent release for bilHng, and a third release 

Iterations of the entire appbcaUon. However, m either case, collections processing. Thus, incremental development 

such extremism ^ not necessary. Instead, a plan can merge 40 funcUonaUty, while iterative development con- 

the two approaches by distmguishmg between the: Unuously refines existing fiinctionality. 

macro, high-level plan, and Incremental development is often more palatable to man- 
micro, phase or team-specific plan. agers than iterative development, because there is no explicit 
In summary, an exclusively waterfall or wholly iterative notion of repetition. Yet, the desirable benefits of iteration 
model are, independently, too simple. Abalance is required. are often realized. For example, releasing consecutive ver- 
Distinguishing between the macro and micro process gives sions of the system creates the opportunity, and often the 
management the intellectual freedom to craft a workplan requirement, to refine the initial release. The early imple- 
that reflects a mix of the two styles. The downside is that this mentation experience can also provide important productiv- 
introduces significantly more effort and complexity in the jty benefits for subsequent releases. This experience may 
planning process. also help drive out technical requirements for future 
The Macro Process for Large Projects Should be Waterfall releases, improving the analysis and design process, 
in Nature Incremental development avoids the complexity of a big 
Managers are Averse to Iteration, because it Expects bang integration. Furthermore, although an incremental 
Re-woik, ipso facto 55 approach deUvers less in each successive release, it can 
The previous section laid out two altematives for com- deliver higher priority portions of the system much earlier 
bining the macro and micro process. For large, custom ^ traditional approach, thereby recognizing business 
development projects, experience has shown that defining benefits in a shorter time frame. 

the macro process along the lines of a waterfall structure is Despite these benefits, incremental development is not a 
most effective. Client and firm project management are 60 panacea. Many times a big bang conversion has proven 

typically uncomfortable with defining milestones and esti- necessary, if the cost and risks of having parallel systems 

mating work with iterations. The common statement is, and bridges, performing conversion, and rolling out training 

"How do I know when I finished the current iteration?'* This are high. These costs must balance those introduced by the 

concern is valid — on a large-scale, "complete*' can be dif- delayed delivery of business benefits and the risks implied 
ficult to define. In addition, most managers have trouble 6S by increasing scope and team size. The urgency of the 

embracing a process that expects and even allows mistakes business and the desire to manage development size may 

on such a large scale. sometimes favor an incremental approach. 
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iDcremeatal Development Can also >^ply to a Single Devel- 
opment Release 

Even when incremental development does not prove 
feasible for entire application releases, the approach can be 
effective on a smaller scale. For example, the development 
and release of a single application may require extensive 
integration of diverse behaviors in a reusable domain com- 
ponent model. The domain components must be put in place 
early to allow reuse; then, behaviors arc incrementally added 
as the business use cases arc analyzed and designed. As in 
the previous case, iteration naturally occurs; but, again, 
incremental proves to be a more acceptable metaphor. 
Enable Top Down and Bottom Up Development 
Different Categories of Tasks should Proceed at Different 
Rates 

Whether applying a more waterfall, iterative, or iocre- 
mental process, the dependencies between tasks require 
careful consideration. Different categories of tasks need to 
proceed from problem-definition through solution at differ- 
ent rates. 

FIG. 48 illustrates the Enterprise Information Architecture 
(EIA) model 4800. This model adapts to component 
terminology, with the relatively minor change in layer five 
from data architecture to domain component model. 
Both Top-down and Bottom-up Models are Necessary 

Hiis model incorporates the idea of simultaneous top- 
down and bottom-up development. Much development 
effort may follow a relatively top-down, sequential 
approach. This includes analyzing and designing: the busi- 
ness environment and processes, domain model, and then 
application. Concurrently, an architecture effort proceeds 
bottom-up. This builds: the technology architecture of plat- 
form system software, hardware and infrastructure services; 
and then application architecture, or frameworks. Top-down 
and bottom-up efforts then conceptually meet in the middle, 
integrating the application framework with the application. 
Both the Architecture and Component Model Lead Appli- 
cation Development 

Hie need to start architecture implementation early is 
well-understood for traditional or component-based client/ 
server development What is different with component- 
based development, however, is the need for the component 
model to lead the application and user interface develop- 
ment. 

Starting the component model early is essential to 
enabling reuse of a consistent, cross-functional set of busi- 
ness components. TTiese core domain components must be 
defined early, at least in preliminary form. Otherwise, the 
simultaneous integration of functionality from many win- 
dows or reports would be extremely chaotic. In addition, 
developers may implement business logic in the user inter- 
face layer, rather than in the biisiness components where it 
can be reused. Furthermore, early design of the component 
model before user interface logic improves the odds of 
creating a pure component model, decoupled from the 
interface. 

Design Efforts Should Focus on Component Interfaces 

Interfaces are the contracts for the services that a com- 
ponent provides. Clients of a component are concerned with 
what the interface specifies, not how it is performed. It is the 
interface provider that is concerned with the implementa- 
tion. By correctly defining interfaces during design, it is 
becomes possible to independently develop components. 
When interfaces are changed, component assembly becomes 
much more difficult and rework is often required. Thus, 
design efforts should pay additional attention to the com- 
pleteness of interface specificatbns. 
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Architecture Development Must Start Early 

A Tension Exists Between Use Cases and Frameworks 

As with client/server, ardiitccture wodc must start early. 
As noted above, this is particularly challenging because of 
5 the level of application reuse in a well-designed application 
framework and domain component model. Because of this 
reuse, the framework must be heavily driven by application 
requirements, or use cases. Yet, the architecture team must 
stay one step ahead of application development teams to 
ensure that the architecture and component model are ready 
in time to be reused. Thus, a difficult tension exists between 
use cases and frameworks. 

The tension between use cases and frameworks can be 
simplified to the extent that third-party or standard archi- 
lectures such as Eagle can be leveraged. In addition, expe- 
rienced architects may bring their knowledge of which 
services are common across applications and can be 
addressed earlier than application-specific architecture ser- 
vices. In any case, the following guidelines should be 
^ considered, particularly for custom architectures: 

The architecture should be defined and prototyped, if 

necessary, early in the preliminary design 
The architecture should be complete-at the very least, the 
development architecture and overall framework, prior 
25 to developers actually coding; the design must be in 
place earlier when functional developers start detailed 
design; private architecture aspects may be deferred 
Time must be planned for architecture support based upon 
unforeseen use cases, performance tuning, documenta- 
30 tion and developer mentoring 

Developing a custom application framework should be 
estimated as a set of tasks in addition to much of the 
traditional technology architecture development 
Failure to Develop the Architecture Early May Reduce its 
35 Efficacy 

If the architecture is not completed ahead of the 
application, developers may have the tendency to build 
architecture services in the application layer. Clearly, this 
may lead to diminished reusability and more difficult main- 

40 tenance. By defining the architecture services early and 
communicating them clearly to the application teams, these 
problems can be avoided. 

A related problem with object architecture and frame- 
works is that the Hue between the application and architec- 

45 ture can become blurred. These architectures may provide so 
much common functionality that it is difficult for teams to 
distinguish who is responsible for what. For example, it may 
not be clear that a function should be provided by the 
application architecture team, technology architecture team, 

50 or application team. This problem can be resolved by better 
communication and coordination across teams. Workcells 
are one approach that has proven effective in this area. 
Component-Based Development Requires More Granular 
Milestones 

55 The Macro Process Uses Traditional Milestones 

The milestones used to track the macro process generally 
remain the same as for traditional systems lifecycles. Project 
management may still be interested in monitoring the 
progress of high-level milestones such as the start and end 

60 of design, or the start and end of construction. 

The Micro Process May Use More Granular Milestones 

On the other hand, the micro process may have more 
granular milestones than traditional systems. Whereas a 
business function in a traditional system may be composed 

€5 of single front-to-back module, a component-based system 
may provide the business function using several collaborat- 
ing components. Thus, component-based systems inherently 
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have more work objects to track. While the increasing During implementation, detailed design and coding steps 

mimbcr of work objects may seem to be a management may overlap. However, the rules and guidelines for sequenc- 

burden, it can provide a more fine-grained reading on the ing these should be spelled out in rigorous detail. Note that 

development process. this does not imply iteration per se, although that may be a 

Another difference from traditional systems is that mile- 5 desirable side-effect if controlled. Rather, this approach 
stones may be more oriented around elements of the systems merely suggests tacticaUy interspersing die design and code 
(windows, business components, and arclutecture activities, particularly to aid in-cxperienced developers in 
components), rather than busmcss fiincUons. Furthermore, transitioning fom design to code, 
some tjjcs of milestones may be more important than define Concrete MUestones with Short Intervals 
others. For example, if there ,s a sigmficant amount of An important difference in managing efforts with this type 
functionality m the busmess components, then there may be - 1 • j * j * if * -i 
««« «,*i^^*«««c. of overlap is the need to define much more concrete mile- 
more milestones associated with the busmess components ^ ^« * . • . , r™ . . . 
than with the user interface shorter mtervals. This is necessary because a 
The Micro Process Should Vary with the TVpe of Develop- ^^^ailed design or coding phase definition loses meaning if 
ment Role ^^^y overlap extensively. Milestones represent more 
The Micro Process Must Compliment the Macro Process concrete, visible accomplishments, such as: 

Assuming a waterfall-like macro process, as described all basic layout and behaviors designed; complex behav- 

above, the challenge of the micro process is incorporating an iors identified, but not completely designed 

effective level of iteration into this management framework. ^iew and application model integrate with domain model 

Different roles for team members require different devel- . , 

opment methodologies. For example, possible roles are: 20 opens 

AppUcation developer— responsible for implementing a ^^^^ ^^^^^ ^^^^ '^^^ 

particular business function, such as accepting bill f^U detailed design of special processing or complex 

payment. This focuses on the application-specific behaviors 

design and implementation tasks such as: working with complex behaviors coded and tested 

a user to define requirements or use cases, designing the 25 Incrementally Add Behaviors to the Reusable Component 

user interface, and implementing application function- Model 

^^y* A previous point emphasized starting the component 

Component Model developer — builds, refines, and sup- model development early, because many of these compo- 

ports the core, reusable business components in the nents are reused in many business functions. Thus, their 

application. 30 preliminary structure must be available before multiple 

Frameworks developer — responsible for the application windows require their use. This implies that many different 

and technology architecture that provide common ser- behaviors may need to be continuously integrated into these 

vices and control logic for the application. components over and over. The component model 

These roles do not necessarily correspond directly to development, then, is very much event-driven like a factory, 

organization assignments. Whether these roles formalize as 35 Incremental is a Good Term for Continuous Integration of 

teams, identities within a workcell, or possibly different hats Behaviors in the Component Model 

a single person wears is an organization decision that The salient feature of this development style is that 

depends on the project size, individual skill sets, and other behaviors are incrementally added to the reusable compo- 

factoES. nent model throughout the development. Iteration and 

Within the Micro Process, More Parallelism Can be 40 refinement often occur naturally in this process. However, 

Achieved incremental proves to be a more acceptable term for man- 

At the micro-level components make it more reasonable agement. 

to execute more development tasks in parallel. Components When developing in this fashion, tracking status is dif&- 

enable this by providing more discrete work objects that are cult. Management traditionally tracks status by number of 

more clearly separated by their interfaces. Because inter- 45 windows or reports complete. Yet, in this style of 

faces are the contracts through which components interact, development, the windows complete may fluctuate dramati- 

the internals of a component can be developed indepen- cally. Some windows may not achieve completion until very 

dently as long as the interfaces are respected. late in the project, when the component model stabilizes. 

Dependencies on Shared Components Need to be Managed Yet, many behaviors may indeed have been completed. This 

On the other hand, since some components may be reused so creates an illusion that the project is further behind than 

throughout the apphcation, it is a good idea to start them reality. More sophisticated status tracking is therefore 

earlier to provide a solid base for the rest of the system. needed. 

Thus, a greater dependency on certain reusable components Iterate to Address Risks or High Degrees of Uncertainty 

may require additional planning effort to correctly sequence Prototypes "Buy Information" that Reduces Risk 

the work. SS Iteration is required to address risks involving a high 

Application Developers Can Folbw a Relatively Formal, degree of unknown. These risks tend to increase with 

Sequential Process component-based devebpment, primarily becaxise of its 

A significant portion of application development can novelty. Thus, the need to iterate is often less intrinsic to 

execute in a sequential manner. This excludes the develop- component-based development and more related to chal- 

ment and maintenance of the core component model and 60 lenges naturally resulting from unfamiliarity. What is now 

application frameworks discussed bebw. For the application "traditional" cHent/server development faced similar diffi- 

developer driving out requirements, design, and implemen- culties years ago. 

tation of window fiinctionality, development can proceed In some cases, this unknown requires experimentation, 

very similar to that of a traditional, cUent/server GUI For example, a throw-away prototype has the explicit intent 

project. Particularly early in development, many aspects of 65 to "buy information" for reducing risk. Prototypes are a 

the methodology can be very similar such as CAR (Control special case of iteration involving less commitment to 

Action Response) diagrams. salvage the work Whether the prototype is salvaged or not 
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becomes less relevant, because the primary value is in the very high degree of iteration, such as technical prototypes or 

information obtained in the process. development of reusable components, should be confined to 

Several different categories of risk require iteratioa. None a small team of experienced developers. These individuals 

of these are unique to component-based development But usually comprise the architecture frameworks team, 

they tend to be more important with component technology 5 One heuristic is to staff the frameworks team with the 

because, again, so much of the underlying technology and most experienced component developers, comprising about 

methodology are new. Some of the types of prototypes are 5-10% of the total team size. There is another reason to 

(These are similar to other definitions): allow the most skilled developers to iterate more — research 

usability, or user interface prototypes has shown that very experienced software developers natu- 

performance prototype 10 rally work more productively this way. Thus, productivity 

proof-of-concept prototype for very talented architects may increase when given fi-ee- 

pilol process prototype ^° iterate as necessary. On the other hand, anecdotal 

These categories may be addressed with throw-away evidence tells us the opposite is likely true for inexperienced 

prototypes, initial working models which arc later refined, or developers. 

some combmation. Use of "prototype^ below generically 15 . This is not to say that application developers should never 

refers to either style. iterate — it's really a question of degree. One approach is to 

User Interface Prototypes Help Users Understand Require- ^^e selected application developers on scout teams that form 

[jjpjj^g for one-time efforts and then disband. These efforts may, for 

User interface prototypes address the difficulty that users example, address an initial pilot process or other type of 

have in defining requirements without implementation 20 P^Jtotypc mentioned above. Even then, these efforts arc 

examples. This phenomenon is analogous to the Heisenberg usually best coordinated by an experienced developer, prc- 

Uncertainty Principle. This law of modern physics states that sumably from the frameworks team, 

the simple act of trying to observe the position or velocity of Difficult Tasks Plan Three Iterations 

electrons affects the result itself. Likewise, usere' percep- ^or those aspects of the system that require iteration, the 

tions of their requirements may be changed, sometimes 25 question still remains, How do I know when I am done? 

dramaticaUy, by observing examples of the potential solu- Experience has shown that three iterations are usually 

tion. In many cases, these prototypes have been used as a required, for example: 

standard design deliverable with repeated review and refine- design and devebp initial working model 

ment with the user. refined working model and pilot 

An important consideration, however, is scope control. 30 roll-out and support 

There is a very complex management problem when itera- The need for three iterations has been observed in so 

tion is iised to drive out requirements with users. Experience many cases that some consider it a magic number. For 

has shown that users may assume that exploring an alter- example, the three iterations defined above parallel very 

native implies that the functionality may be implemented. closely a maxim quoted by Kent Beck, a well-known 

Thus, some change control procedures need to be defined 35 Smalltalk expert, Make it run, make it right, make it fast, 

and managed, even if they do incorporate some flexibility to Difficult Components Should be Designed and then Proto- 

incorporate enhancements. typed 

Performance Prototypes Address Global Architecture Issues An initial working model phase designs and prototypes 

Performance prototypes primarily address technology the component or fi-amework. Prototyping may be necessary 

architecture questions. For example, the architecture team 40 to evaluate two or three altemative approaches. In these 

may need to decide early on whether to use messaging, cases the initial design represents a strawman, until receiv- 

remote procedure calls, or shipped SQL statements for ing validation from implementation. Only then can things be 

distribution services between client and server. A prototype finalized and reviewed for sign-off. 

is often the only way to identify the most effective solution. Piloting Reusable Components with Developers is Neces- 

Proof-of -concept Prototypes Address Complexity 45 sary 

Proof-of-concept prototypes address areas of significant During the refinement and piloting phase, the component 

technical or fimctional complexity. In the most extreme case, or framework is completed with any remaining functionality 

the team may be uncertain as to whether they can even and then used in a pilot case. Coordination is often necessary 

develop the logic within the specified quaUty parameters. Or, with a pilot developer who is a client of the reusable piece, 

it may be too difficult to design a solution upfiront, because 50 to ensure that it works in an appropriate use case. Typically, 

of a mix of technical, functional, and maintainability issues. the pilot process generates several refinements or changes. 

In such cases, the team may need to implement alternatives Pilot developers need a flexible, positive attitude to handle 

for evaluation. potential instability. 

Pilot Process Prototypes Provide Experience for the Team The component must then be documented and roUed out 

Pilot process prototypes are used primarily for the team to 55 for reuse to all developers. In many cases, the roll-out 

gain experience. TTiey typically use a front-to-back, slice of requires a formal group meeting to answer questions. During 

the application. This is similar to incremental development, the support and refinement phase, the component is refined 

which delivers the solution to a portion of the business as other use cases generate new requirements, and bugs or 

fimctionality. Such learning benefits are not unique to pilot performance problems are identified. Although the imple- 

prototypes. The distinction of a pilot prototype, however, is 60 mentation details of the component should not be widely 

that gaining experience is the primary purpose of the effort. known, it is critical that developers thoroughly understand 

The learning may focus on technology, business function, or the purpose and public behaviors of the component. If they 

methodology. do not, then they may not be able to effectively reuse and 

Confine Highly Iterative Tasks to Experienced Framework debug interactions with it. 

Developers 65 Summary 

Iteration demands very experienced developers, to under- A traitional client/server implementation often incorpo- 

stand the criteria for completion. Thus, tasks that require a rates some limited iteration with a waterfall approach. TOs 
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iteration is usually confined to technology architecture tasks. In fact, several stages of integration must occur to complete 

Component-based systems tend to require somewhat greater a single window. 

iteration for three key reasons: Consider a customer that encapsulates other related com- 

. * 11 . . ponents such as credit profile and address. This customer 

Reusabihty often requires achially reusmg the component ^ ti^^ even reprc^ nts too much functionality for an 

to ensure the reused piece meets requirements 5 ^.^.^ component test. Simpler components such as the 

Component technology is new, thus iteration helps address must be tested first. Testing individual components 

address greater technical risk or tightly coupled aggregations should occur in the initial 

Component skills and methodologies are emerging, there- component test phase, 

fore the team often gains valuable experience from Th^ assembly phase then tests tiie integration of these 

iterafinn 10 components. This test phase differs from a traditioaaJ assem- 

} . . . j-ic 1. t_ . -LI XT 11 *t. t>ly test, because more components must typically be 

Managing iteration is difficult but possible. Usually the j^fegrated, particularly for the vertical, front-to-back jiinc- 

plan must mcorporate a hybnd of waterfall, incremental, and tionaHty from window to database. This adds to the hori- 

iterative models as appropriate. The right process depends zontal integration of interdependent windows in a dialog. In 

on the organization or teams* skills, the degree of technical contrast, a traditional assembly test concentrates much more 

risk, and the specific application and business requirements. heavily on the horizontal dialog test, since the fi-ont-to-back 

Testing window functionality is often just a single module. 

Testing typically consumes anywhere &om 50-80% of Th© timing of the assembly test may vary depending on 

development effort. Despite this relative importance, testing development teams organization. If there are anumber of 

receives little emphasis by component-based developers working on a toc^^^^ 

J , . V • . r • -1 I • J 20 then early mtegration helps to ensure that developers are 

methodologies, which focus primarily on analysis and working in concert and simplifies integration later, 

design techriiques. This section presents testing lessons Conversely, the issues of integration may not be as signifi- 

consistent with the primary themes in The Testing Process cant if a single developer is working on an entire business 

Practice Aid, produced by the Re-inventing Testing Project. function, end to end. 

These points merit increased emphasis, however, because In summary, the collective atomic, component, and 

experience has shown component-based systems increase ^ assembly test phases require much more detail in terms of 

testing complexity. milestone definitions, status tracking, and methodology 

Testing is More Complex development. ^ 

While a component-based approach may be simpler to J^^*"^g Component CoUaborations Must Occur m Several 

test than a strictly object-oriented approach, testing is still r**- j-* *• uu - ^i 
1 ,t ' J 1 * u ♦30 The process of testing and integratmg behavior of col- 
more complex than a procedural system, because component 1 , ^ * w 1 1 1 T 
, . ^ ^ ' ^ laboratmg components must occur at multiple levels. In 

architectures. particular, distinguishing between the component and 

decompose into a much greater number of components assembly test phases can seem somewhat arbitrary. A weU- 

than equivalent procedural modules, introducing more factored architecture may have identifiable boimdaries, 

complex technical integration adiieve a greater level of however, as noted above. Thus, coming up with good 

reuse, which is a blessing once highly reusable pieces definitions of aggregation — that is, cohesive groups loosely 

stabilize, but remains a substantial challenge whde they coupled from other groups, is equally critical to testing as to 

undergo development design. The component aggregation must then support an 

utihze flexible, messaging between components that ere- effective partitioning of the application architecture and 

ales a larger number of potential test execution paths ^ organization. 

usually develop with some degree of iteration, which Testing Requires a Flexible Organization 

jeopardizes the benefits of phase contaimnent , ^n large projects, the set of components mvolved m a 

Testing Requires More Phases busmess event are often developed by many different 

-n. % ? r. J « *u 4. people. Thus, the complexity of team mtegration further 

The Testing Process defines a three-step process, very ^ ^ ^ 'i_ ^ ^- * ^i? n j ^ j 

• M ^ ^ j-^- iT.*.i.jrt complicates the testmg effort. Well-defined component 

smiilar to traditional Method/I, as follows: 45 boundaries in the software and organization are certainly 

component test— a test of an mdividual module or pro- j^^y. However, the organization must expect the need to 

gram that is specified and coded as a single unit support flexible integration testing teams that form to ensure 

assembly test — a test of a set of programs that commu- a particular business function works correctly across parti- 

nicate with each other via messages or files, usually tions. 

equivalent to a user interface dialog or a batch string 50 Testing Effort Shifts Earlier in Development 

product test — a test that verifies the technical and func- The System Test Phase Should Go Faster 

tional implementation supports the business process implications of greater modularity and flexibility 

Object Systems Require an Initial Atomic Test Phase discussed above increases complexity in the atomic, com- 

When bmlding components using objects, testing can Pon&nt and assembly tests. Once the architecture and highly 

logicaUy foflow these same three primary phases, at a high 55 reusable components m the component model stabilize 

level,precededbyaninitialatomictestphase.Anatomictest however, system test is simplified Hius, component-based 

phase is required because a well-factored object system may ^^^^^^f .^^'l^^ ^^"^^ ^^^^^ ^° ^^^^1- 

onment liiecvcle 

typicaflyhaveatleast lOtimesmoreob^ p^^^^ Contakment Requires Greater Attention 

modules m a traditional system. This finer granularity Experience has sho^ that defects become increasingly 

requires testmg^d mtegratmg more units at multiple levels. 60 ^^^^ expensive to fix later in the development cycle. Phase 

Completmg a Wmdow Requires Several Stages of Compo- containment strives to decrease both the number and cost of 

nent Test and Integration fixing errors, by testing steps early in the development 

Atraditional approach often defines the mitial component lifecycle through verification and validation of work. FIG. 

(unit) test as a working window, front-to-back In a 49 illustrates a V-model of Verification 4900, Validation 

component-based architecture, on the other hand, a window 65 4902, and Testing 4904. Exit criteria might involve, for 

may often utilize behaviors of several components. This example, compulsory detailed checklists or code reviews 

results in too mudi integration for an initial component test. before work is promoted to the next phase. 
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While phase containment is not unique to component All of the above considerations result in substantial 

development, its importance is heightened. Since many re-testing. Enough so, that a manual approach to regression 

portions of the component model may be reused by literally testing can be extremely cumbersome. In particular, changes 

every window developer, quality is criticaL That is, a high to shared components or changes at or near the root class of 

quality design and implementation for core components 5 a deep inheritance hierarchy can have widespread impacts, 

increase the productivity of every developer; however, the Thus, automated facilities for testing should be considered a 

converse is also true — mistakes tend to penalize aU devcl- mandatory element of component development, 

opers. Thus, thorough testing and attention to quality in early Combine Automated Testing With An Automated Build 

development steps is important. Process 

Iteration Complicates Phase Containment lo Automated testing can also make the configuration man- 
Yet, incremental or iterative development complicates agement process more cflBcient. By using an automated test 
phase containment. Phase containment presumes a waterfall process to verify that the latest version of the application is 
model. For example, a module or component should not be working correctly, it is possible to give the development and 
passed to a later phase such as coding until the design has testing teams more stable releases. For example, simple 
been validated and verified. In contrast, overlapping design 15 defects such as incorrect interfaces can be detected before 
and code implies coding starts with an incomplete design. the application is even distributed. 
This puts at risk any efforts to define precise milestones so GUI Scripting Tools Alone arc Usually Not Su£&cient 
critical to effectively track progress. Capture-playback GUI testing tools have proven effec- 
Iteration Requires More Detailed Exit Criteria tive. However, for many applications these are not com- 
Thus, iteration requires more detailed completion criteria. 20 pletely suf&cient. Hiese tools may only re-validate that the 
For example, different iterations of design must have very application appears to function properly. Experience has 
explicit scope boundaries to ensure that the completion of an also shown that applications may sometimes use widgets or 
iteration is adequately defined. These must be accompanied technical elements of the user interface not supported by a 
by strong adherence to proper procedures as components are particular tool, 
promoted through various development stages. Even with 25 Self-testing Features Should be Built 
such efforts, however, experience has shown that later A more comprehensive testing framework should be 
designs tend to impact previously working code. Significant considered that incorporates the notion of self -testing com- 
regression testing must be expected, as discussed below. ponents. That is, the component may have behaviors, or 
Automated Regression Testing is Usually Necessary indeed contain a tester component, that feeds the class a test 
Regression Testing is Necessary Because of Iteration, 30 suite, and validates the resulting behavior. Note, however. 
Inheritance, and Extensive Reuse that test components rarely test behaviors of just a single 
Experience has shown that the higher degree of reuse in component in isolation, because any meaningful behavior 
an component model and application framework makes it usually cuts across multiple components. The test can still 
very diJB&cult to protect implemented components from obey encapsulation, though, by testing the group as a single 
subsequent development. Developers must then verify pre- 35 black-box, rather than taking short cuts which may under- 
viously tested components as they incrementally add func- mine the vaMdity of the test, 
tionality to the system. Automated regression testing can Testing Frameworks Requires More Attention 
save time by ensuring that areas that are impacted by The use of frameworks in component-based systems also 
changes are properly tested. increases the complexity of testing. Frameworks add corn- 
Moreover, regression testing capabilities are absolutely 40 plexity for the following reasons: 
essential if an extensive architecture framework is devel- Foreseeing all the uses of a firamework is hard a priori, 
oped. Component-based development allows an application Thus, verifying correct behavior is difficult because the 
framework to abstract both technical aad functional behav- test cases may not be complete, 
iors Hiis greater level of reuse necessitates that the frame- ^^^^ ^ ^^^^^^ extensive scaffolding to 
work evolve with the development of the apphcation. 45 emulating the appHcation intended to use the 
Unfortunately, this implies changmg the techmcal environ- framework. 

ment of the application even as it approaches delivery. To _ i j i ^ • u j ^ i i • 

effectively support these enhancements requires re-testing at Framework development is usually undertaken early in 

many different levels. ^ ^ the project so that it is ready to support application 

Usiii Objects Increases the Need for Regression Testing 50 developers imphcs mcomplete knowledge of 

When developing components using objects, regression requirements fi^r the frameworks team, 
testing becomes even more important. For example, inher- stakes are high, because the framework usually 
ilance often results in sub-classes coupled to their parent. A provides a reusable structure for many developers, 
parent class may have side effects with subUe impUcations Th®^^ essentially two methods for testing a frame- 
to children, which are difficult to identify for test cases, 5S work: 

Experience has shovra that even seemingly innocuous Emulation approach — by building a comprehensive test 

changes to a parent can damage previously tested sub- environment that emulates the application, 

classes. Pilot approach — by using apphcation developers as pilot 

In general, an inherited feature must be retested in the users in the testing process, 

context of the subclass. Retesting can only be avoided if 60 The emulation approadi protects application developers 

subclasses are "pure'' extensions of their superclasses; that from the testing effort, and is generally more consistent with 

is, if they don't override any methods and do not modify a formalized approach. Not doing so opens the door to 

inherited instance variables. Furthermore, test cases usually rolling out untested frameworks. On the ottier hand, creating 

cannot be inherited when overriding a method. Slight dif- a redundant simulation environment of the application use 

ferences in logic and data declarations are indeed enough to 65 cases can be expensive. 

invalidate the superclass' test cases, requiring new test The pilot approach may be more productive by leveraging 

definition and input data. real application code. In addition, it encourages training and 
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knowledge transfer to developers. Finally, it helps ensure deliverables completed in previous phases. In addition, there 

accurately covering requirements. It is important to use is a strong desire to link deliverables and requirements from 

application developers for the pilot, not the architects. This the earlier phases to the deliverables from the subsequent 

may provide an objective review of the framework^s usabil- phases. 

ity. The primary drawback is that it takes a developer away 5 On a typical project one finds the following tools used in 

from the application; and, as noted above, may result in the software development process: 

frameworks developers feeling relieved from thorough test- General diagramming tools: Visio, ABC Graphics, etc. for 

ing. Experience has shown that a hybrid of the two is usually workflow and operation diagrams 

necessary, ^§ Office : Word class and component specification 

Summary lo templates, Excel scenarios. 

Experience has shown that initial component develop- ^l .^-.j^aof-. 

mem projects require more effort in testing. On the other 0'»J««" Onented CASE tool: ckss and component models, 

hand, the later sUges of testing can be more productive by component/class specifications, message trace dia- 

effectively leveraging encapsulation of components and grams 

large-grained components. There is reason to believe that 15 Database design took: Erwin, Oracle Designer, etc. 

these benefits can be leveraged sooner if the team pays Integrated Development Environmcnt(IDE): Visual 

increased attention to testing early in development. Testing Studio, N^sual Age for Java, JDevclopcr, \^sual Cafe 

should be a part of the entire development process compris- Source code configuration manager: SourceSafe, Clear- 

m- Case 

phase containment principles with explicit objectives and 20 An inordinate amount of time is invested in the macro 

exit criteria such as checklists and peer or lead reviews process of how to capture and link information in a way that 

automated regression testing capabilities it tie used efeectively through the course of the project 

self-testing components (^'S-, moving the models from the CASE toolinto the source 

J ^ . , ^ code of the targeted IDE environment). Teams should tackle 

more detailed testmg phases and milestones ^5 early the selection of deliverables in each phase and which 

comprehensive procedures with disciplined enforcement tool the deliverable may be created and maintained within. 

Development Architecture Considerations in addition, they should determine whether the deliverable is 

Ihis section highhghts key messages for development to continue to be enhanced in subsequent phases of the 

architecture teams in regard to supporting teams and tools project through the iteration process, 

within a component based development project. 30 Today's Dilemma ... No Easy Answers, Yet 

Building systems that are dramatically more responsive to ^^^^^ ^ environment that enhances the productivity 

change require a dramatically miproved development archi- y^^^ ^^^^ programmers is a challenge for any 

^^^.^i^' , . - . . „^ project, but for projects building component-based 

What does It niean to be more responsive to change? Hie ^^^^^^ -^.^ ^^^^ ^^^^ ^^^^^ ^^^^^^ ^^^l^^^l^. 

soluuons one builds must be more: 35 ^^.^ ^^^^^ immaturity. You won't find any easy answers. 

Flexible. Making it possible to replace or modify appli- ygt. 

cation components with minimal impact to the other Generally speaking, the resulting environment gets the 

components in the system. j^^i done, but consists of tools that are crudely integrated 

Scalable. Giving you freedom to distribute and reconfig- with no central repository. This results in redundant data and 

ure application components to meet the scalability manual cross-referencing. It can also cause problems during 

requirements of the client. the transition fixim Design to Construction % a gap that*s 

Integratable. Allowing you to reuse the functionality always been difficult to traverse. Other typical concerns 

within existing systems by wrapping them as compo- include a tool's ability to meet usability, scalability, and 

nents within the new application. multi-user requirements. 

Adaptable. Giving you freedom to deliver an application Ideally what would greatly increase the productivity of 

to a variety of user types through a variety of delivery the devebpment architecture is a seamless integration of 

channels with minimal impact to the application itself. tools in the workbench and the ability to "plug in" whatever 

Reusable. Making it easy to quickly assemble unique and tool is most appropriate for the capture and communication 

dynamic solutions from reusable components. so of a particular deUverable. HG. 50 portrays a development 

Component-based development pushes us forward on all architecture with a seamless integration of tools x^^ich can 

of these dimensions, and although it's relatively immature, ^® pliigged in for the capture and communication of par- 

we're better off than we were before. Metaphorically ticular deUverables. Shown in FIG. 50 is the relationship 

speaking, we've climbed very close to the top of the between a process phase 5000, deliverables 5002, tools 

mountain that represents traditional development. The view 55 ^^'^^ repositories 5006, and an information model 5008. 

is satisfactory, but we know there is something better, so One solution center working on this architecture found 

now we're climbing the mountain that represents that the current state of integration with tools was so 

component-based development. We have yet to reach the constraining that the picture in FIG. 50 had to be resolved 

top, but we're already higher than we were before. with many compromises for new component work. There 

On every component-based development project, teams 60 were many custom scripts created and manual processes 

spend time evaluating and establishing the environment in defined for leveraging the flow of information between 

which analysts and developers create the deliverables. A phases and tools. 

workbench must be established that expedites the flow of FIG. 51 shows a design architecture with the compro- 
deliverables through the different phases of the project. In mises made for today's component construction environ- 
component- and object-based solutions, these phases are 65 ment. Shown in FIG. 51 is the relationship between pro- 
very connected. This is largely because each subsequent cesses phases 5100,deliverablcs 5102, tools 5104 and 
phase tends to be an elaborarion and refinement of the storage 5106. 
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Key Considerations 

A development architecture should provide an environ- 
ment for component-based solutions that supports a team 
through the Analysis, Design, and Construction phases of 
the development process. It should also serve as a productive 
environment for the on-going maintenance of an application. 
Conceptually it should integrate all of the necessary tools 
through an information model and most ideally through a 
central repository. The following arc considerations that all 
component development architecture must consider. 

1. Support Custom Process. The present invention uses a 
robust process for developing component-based solu- 
tions. It includes deliverables that are above and beyond 
the Unified Modeling Language (UML). Furthermore, 
projects often customize it. The environment must pro- 
vide the ability to extend the information model (i.e., the 
meta-model). 

2. Versioning & configuration management. The environ- 
ment should provide the ability to version objects within 
the common information model at any level of 
granularity, keeping track of these changes over time. It 
should provide the same ability for composite objects 
(i.e., configurations of smaller objects). 

3. Scalability. The repository-enabled environment must be 
able to support hundreds of users simultaneously, and 
hundreds of thousands of repository relationships. It 
should also scale downward, so that small project can use 
it. This is a major criterion for usability. 

4. Query and impact analysis. As organizations begin to 
maintain their own component-based assets, they must be 
able to analyze the impact of change requests (e.g., 
where-used searches). The ability to trace requirements is 
also critical. 

5. Asset catalog (reuse). As organizations begin to reuse 
existing assets, it may become increasingly important to 
provide a catalog of components, frameworks, patterns, 
etc. The catalog should make it possible to search for 
relevant assets in a wide variety of ways. It shoxild also 
provide a means for applying frameworks and patterns. 

6. Code generation. The ability to generate the application 
structure from the model is essential to high productivity. 
Furthermore, this step should be transparent to the user. 
As far as the \iser is concerned, a change to the model is 
a change to the code. 

7. Desktop Tool Integration. The repository-enabled envi- 
ronment must provide integration between all desktop 
tools (e.g., MS Office, Visio, 00 CASE tools, designers, 
etc.) through component object models such as ActiveX. 
In addition, these tools must have access to the common 
open information models. 

8. Non-redundant storage. The environment should avoid 
redundant storage of information, whenever possible. 
Everything from training to documentation to active com- 
ponents should be automatically updated or notified of 
changes. 

9. Multiple users and locations. Many users may need access 
to the environment during the course of a development 
effort. Furthermore, because one supports global commu- 
nities of practice, there is a strong need to share this 
information securely and across disparate locations. 

A Development Architecture Needs to Support Customiza- 
tion of the Process 

UML & Case Tools in the Development Architecture 

Each project using component-based technology deter- 
mines how to use 00 CASE tools to support an object- 
oriented methodology and its deliverables. Hiese deliver- 
ables range from high-level business process documentation 
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in the business-modeling phase to descriptions of classes in 
the construction phase. UML compliant CASE tools provide 
a number of the deliverables that most object methodologies 
uses, however, there are almost always some deliverables 

5 that do not fit in the selected tool. There is also a discrepancy 
with the CASE tools' ability to comply with UML due to the 
continuing evolution of UML versions. 

UML has become so universal now that deliverables from 
most methodologies form a superset or, in some cases, a 

10 subset of the deliverables described by UML. In the case 
where a deliverable is a close match to a UML deliverable, 
proprietary scripting is required to allow for complete 
semantics. This scripting is also used to migrate from the 
CASE tool to other drawing or word processing tool Pro- 

15 ccdures must also defined to effectively use the tool to 
support the process. 

Decide on Supported Deliverables Early in Process 

Case tools in recent years have extended their ability to 
support more of the life cycle and improved their case of use . 

20 In addition, some case tools have improved thek integration 
with the Integrated Development Environments (IDEs) and 
produce some level of acceptable component code genera- 
tion. It is important for the development architecture team to 
determine early exactly which deliverables may be created 

25 in each phase of development, which tool they may be 
captured in and whether links between phases require 
upgrading deliverables as a result of the transformations 
and/or enhancements from other phases. 
Hie team must decide how much they may leverage the 

30 automated tools to support the build process. An investment 
in the macro infrastructure can lead to tremendous time 
savings as the construction process is supported. The team 
needs to determine early whether they may "build" their 
custom process into the tool or adjust the process to better 

35 integrate with the tool. 

Development Architectures are Often More Heterogeneous 
than Traditional Environments 

While traditional client/server systems typically required 
one development tool for programming efforts, component- 

40 based systems are often built using several tools and pro- 
gramming languages. The increase in tools is directly related 
to the improved capability to integrate software components 
through interfaces that hide the implementation details. 
Typically, the more heterogeneous environments may be 

45 built upon the open CORBA technology, while applications 
developed with JavaBeans or COM may tend to be more 
homogeneous in nature. Thus, it is important to understand 
the technologies XLsed as the effort to design a cohesive 
development architecture may be impacted. Plan to ^end 

50 more time designing and building the development archi- 
tecture for a heterogeneous environment. 
Configuration Management 

The advent of client/server has focused significant atten- 
tion on the importance of configuration management as key 

55 to success. Configuration management is more than just 
source code control It must encompass the management of 
the application software components from conception, 
through implementation, delivery, and enhancements. While 
the problem is not unique to component and object 

60 development, an object-oriented environment presents spe- 
cial challenges discussed below. 

Configuration Management is More Complex in a Compo- 
nent Development Architecture 

Currently, artifacts versioned with various tools do not 
65 know about each other. For example, an object versioned in 
a document management tool has no relationship to the 
source code configuration. In addition, various tools are 
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advertising the advantages of their repository strategies. Adopt a Philosophy for Configuration Management that 

However, these products are in their infancy and most do not Guides the Development of the Process 

integrate seamlessly with the source code configuration There are two fundamentally different approaches to 

managers let alone the various tools in a development configuration management in the component world. Simply 

workbench. Models, source code and documentation are not 5 stated, they represent the difference between an optimistic 

synchronized. The reality is that current versioning in the approach versus a pessimistic approach to managing 

majority of tools only occurs at the file level and not at the sources. In the optimistic approach multiple users can access 

required level of granularity to support development clc- and modify the same sources and the tool is leveraged to 

ments. Methods, classes, components, and their respective resolve conflicts when code is merged. In the pessimistic 

deliverables should be versioned but only a few products on , approach a source is locked when it is checked out. Both 

the market today support this level of granularity and they advantages have pros and cons and some source control 

are not yet integrated with popular case tools. managers allow the configuration to choose which approach 

Object Systems are Decomposed into More Pieces j^j^y choose 

Configuration management is more complex with object ^^^^ ^^^^ ^^ Levels of Ownership 
developmentbecausethesystem^^^^^ ^ traditional, procedural system usually assigns owner- 
Object development reahzes the benefit of flexibility and ^5 business function. Functional developers take on 
reusability through a greater level of decomposition than -l-i'*, r i_ • a . j ^ 
was present in tSditional systems. While smaller objects ^^^P^^^bihty for a buaness fiinction that corresponds to a 
have the advantage of making it easier to have pre-defined ^ont-to-back wmdow Technical team developers then take 
building blocks, a disadvantage is that large-scale systems cross-funcUon architecture responsibihty. This approach 
have so many elements that managing their relationships 20 obvious benefits in providing straightforward commu- 
becomes difiBcult. nication points and division of responsibility. A drawback, 

For example, a key principle of object-oriented design is however, is that business function reuse is much more 

separation of concern, which decomposes behavior into difiScult. 

smaller, more cohesive objects. This strategy strives to This approach breaks down due to the higher level of 

prevent changes from rippling through many objects. The 25 reuse in an object-oriented system. Note that a procedurally 

implication of this design approach, however, is that the designed system may also experience this problem to the 

resulting system may comprise many more modular pieces extent that the team strives for a large degree of business 

than a traditional architecture. This greater decomposition logic reuse. 

complicates configuration management. Owners Must Exist for Every Versionable Component 

Not only are there more objects than procedural modules, An object-oriented system must assign component own- 

the relationships and dependencies intrinsic to object devel- ership at multiple levels. Business process owners are still 

opment are usually more complex. For example, the rela- necessary; however, clear lines of responsibility must be 

tionship between business processes and objects is a assigned for the domain object model. Often these two may 

complex, many -to-many mapping: a business process is have a tight relationship. For example, consider a gas utility 

implemented by more than one object; conversely, an object 35 customer system that provides customer service orders. The 

contnbutes to more than one business process. FIG. 52 service order business process and service order domain 

illustrates a business process 5200 to object 5202 mapping object owner should probably be the same person. However, 

to illustrate such relationships between business processes the service order process may also need to collaborate with 

and objects. One manager referred to this phenomenon as other key domain components such as the customer and 

the web of interdependendes. premise. This requires collaborating and communicating 

To manage this problem determine early what the "unit" with other developers, 
of configuration may be and have the development organi- Rigid Ownership Boundaries May Not Work 
zation aligned with the approach. For example, in the Experience has shown, however, that the level of corn- 
previous maze possible units of configuration could be: munications with core business objects such as customer and 
Process 1 depends on: 45 bill account is so high that the rigid ownership might be 
Object 1 ineffective. The resulting communications of requirements 
Obj ect 2 ni^y produce inefficient hand-offs and bottlenecks. For large, 
Object n mission-critical applications, multiple levels of ownership 
This keeps the process component rigorously configured defined. However, this creates a risk of 
with its dependent pieces. 50 conflicts. Before components mature, the rules of divisions 
Configuration Management Requires a Comprehensive ^^^^^^ probably be more rigid. Later, multiple developers 
Approach can modify common classes, while keeping responsibihty to 
Most Object CASE Tools do Not Support a Complete, release, or publish, the code in the hands of a single owner. 
Integrated Repository Thus, ownership roles may overlap, requiring the rules of 
Integrated tools have, thus far, not been found to support 55 engagement to be defined. Yet, every scenario cannot be 
cross-referencing window elements, object model attributes spelled out precisely. The team and leadership must then be 
and behaviors, and relational database definitions. Tlius, ^^^y. participatory and flexible to adapt to the dynamic 
large projects must consider crafting a strategy to integrate requirements. 

multiple point tools to provide such cross-referencing. &igagement Defined Separate, Overlapping 

The tools gap raises the importance of rigorous procedural 60 Ownership Responsibility for: 

and organizational models to address configiuration manage- Windows 

ment. For example, proper procedures must ensure that Domain object model sub-systems, or components; the 

rigorous quality and build steps are followed before intro- model comprised about 350 model objects which were 

dudng a new component into the environment; the worlq)lan partitioned into about 12 major areas 

requires much more detail to track dependencies; and, the 65 Business processes that were particularly complex, highly 

organization structure must effectively support more cxten- reusable, and cut across many windows; for example, 

sive communications to react to changes. writing off a bill 
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Common architecture framework components 
Separate concept of ownership from developer for 

increasing productivity 
One solution to the above problem is the clear distinction 
between component ownership and developer rights. This 
philosophy is supported by tools like Envy/Developer for 
Smalltalk and Visual Age for Java. Assign owners of classes, 
packages, and projects and then assign developers to the 
packages. Any devebper may write methods on an open 
edition or checked out copy of a class. The owner of the 
class can release the methods to the class, version the class 
and release to the general development team. In this model 
editions are open configuration units, versions are any ;mils 
that have been checked back in and releases are units that 
have been made visible to the next construct of configuration 
management. 

In this model clients of lower Level components can be 
added as developers in the integration phase. Rather than 
have to wait for a new version of the component, they can 
concurrently have an edition opened with which they can 
modify or enhance and then submit their changes back to the 
component owner. This practice can keep control with 
component owners but increase the bandwidth of the devel- 
opment cycle. 

Application Packaging must have a Clear Release Manage- 
ment Strategy 

To support a flexible ownership model requires a detailed 
technical packaging strategy. Multiple levels of granularity 
for controlling source code are typically needed. The method 
and class are obvious targets for versionable components. 
However, levels of granularity above the class are critical to 
properly control the cross-class development that occurs. 

Typically development may occur on groups of classes 
which can be versioned together as categories or ^plica- 
tions. In Java, for example, these categories are packages. 
For example, the frameworks development team may gen- 
erally have a work-in-process version of the framework 
architecture package to support new development. Applica- 
tion developers would instead have an older version, typi- 
cally the first version, that had been thoroughly tested and 
rolled out. 

It may also be necessary to version groups of methods 
together in a class. This has proved beneficial for managing 
object model development 

Components of the system should also have a well- 
defined [EWFl] relationship between them. This should 
occur at each level of granularity and give a definite feel for 
the dependencies between components. Each instance of a 
component also needs to know the specific, tested compo- 
nent versions with which they are compatible. It is essential 
that the relationships between components are non-cyclical 
or layered and that a complete dependency inventory be 
obtainable for every versionable component 
Favor Shorter Shelf Lives to Support Frequent Roll-outs of 
Reusable Objects 

One of the most difficult decisions for object development 
is how frequently to rollout reusable components to mul- 
tiple developers. And a related issue is how long component 
should sit on the shelf between changes. 

For a traditional, waterfall approach the shelf lives may be 
quite long with few iterations. For example, a modiile is 
typically coded and then put on the shelf until string test. The 
elapsed time ranges from a few weeks to many months. 
Likewise, once string tested the module may again sit for a 
long time until system test. These long shelf lives typically 
work reasonably well unless the underlying data model or 
architecture changes. In this case, unproductive re- work 
results. 
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The Object Model Must be Continuously Rolled Out to the 
Team 

For object development, roll-outs of objects must occur at 
varying inters^als depending on the range of impact. Because 
5 the object model is continually evolving as completed 
windows incrementally add behavior, the model must be 
continually refined and rolled out to the team. Some of these 
changes may have a very narrow impact to just one window, 
where others may have more global implications. 

For example, changes may be rolled out in the following 
intervals: 

Application Interface or Control — nighdy 
Narrow Impact Object Model — ^nightly 
Wide Impact Object Model — coordinated on-demand, no 
15 more than 1-3 times per week 

Frameworks — weekly or less frequent depending on 
impact, maturity of the component, and the complexity 
of the effort 

Structural Object Model — ^for Data Waves, Once Per Month 
20 Object development also requires shrinking the shelf lives 
dramatically. Reusable domain model and framework 
objects generally reqmre a zero tolerance policy for incor- 
rect code. Problems need to be fixed immediately, or at least 
their impact critically assessed and the fix scheduled. As 
25 mentioned earlier, some of this immediacy can be managed 
with careful process surrounding ownership, editions and 
developers. In one tool there is a concept of a scratch edition 
that allows a non-registered developer to access units of 
control and make changes within his private environment 
30 and still be able to post the changes back to the component 
developers and owner. This eliminates hours or day turn 
around to correct a critical problem in a versioned compo- 
nent. 

Clean-up or Fix-it Days Miist be Scheduled 
35 Window or view specific behavior can have a longer shelf 
life, but still not as long as traditional development Letting 
items sit for more than even just a few weeks can cause them 
to become dangerously out of date. Thus, two different large 
engagements found it necessary to schedule clean-up fix 
40 days on a regular basis. 

Regression Testing is Key to Effective Configuration Man- 
agement 

Regression testing is essential to support these more 
frequent clean-up efforts. This approach frustrated 

45 management, because these days appeared to be a step 
backward or treading water. However, keeping the applica- 
tion clean paid dividends in addressing and fixing problems 
more efficiently. Generally speaking, the longer the problem 
went unfixed, the more expensive they were to correct. 

50 In summary, a flexible approach is necessary to coordinate 
and control changes. Some considerations include: 

Ability to absorb change — If the developers are over- 
whelmed with change or learning curve, the shelf life must 
be expanded to reduce change. 

55 Magnitude of the change — Minor changes may be easy to 
incorporate and may facilitate immediate turn around. Major 
changes may be expensive to incorporate except at 
controlled, regular intervals. 
Restart Cost — Each effort to integrate changes into an 

60 existing component may incur a start up cost for the devel- 
oper. This may again be influenced by the magnitude of the 
change, and the duration of the integration cycle. A rapid 
integration cycle may keep the behaviors fresher in the 
developer's memory; a longer shelf life may involve a 

65 refamiliarization cost. On the other hand, this miist be 
balanced against the cost of starting and stopping new 
development to implement fixes. 
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Stability — ^As a component stabilizes and matures, the 
shelf life can be reduced without impacting the rest of the 
project. Unstable object components cannot be rolled out as 
frequently, because the turn-around time is longer. 
Delivery Capability — The ability of the migration team to 5 
provide a "most current" build may also impact the fix 
versus shelf decision. In C++, the build process may be 
a major undertaking, where the shortest shelf life may 
be measured in days. In Smalltalk, the size of the image 
may likely have a similar affect. In Java the adherence 
to clearly defined packages improves the delivery capa- 
bifity. 

Configuration Management May Require 5-10% of Devel- 
opment Team 

Configuration management clearly requires more effort 
with object development. These roles arc often hard to 
jiistify to management, because they appear to be pure 
overhead. The tasks may also appear unclear. For example, 
tasks such as "Manage environment" and "Communicate 
changes" do not to have a start and a finish. 

These tasks should be controlled and managed by a 20 
centralized effort. Several people sharing the effort in their 
spare time may not exercise enough caution and due dili- 
gence. Furthermore, a centralized effort may often result in 
automation of tasks producing significant productivity 
improvements, 25 

At least 5% of the development team should be com- 
pletely dedicated to the on-going configuration management 
effort. When setting up and defining the environment even 
more resources may be necessary. Of course, there are 
Umits. Stacking the team with too many resources may result 30 
in wasteful development of an overly elaborate tools archi- 
tecture. 

Another approach is to make the configuration process 
implicit in the entire development process. In other words, 
by ensuring that an owner of a class must version and release 35 
his work before it can be seen by a containing package the 
owner is required by the process to be thinking about the 
configuration process in all of his work. Subsequently, the 
package owner, generally a more experienced developer, 
must ensure that all classes are versioned within his package, 40 
version his package and then release it for general consump- 
tion. This would work the same for a project which tends to 
be centered aroimd increasing units of capabilities (Le. 
business activities and finally whole applications). 
Scaling to Large Teams 45 

Despite the advice to use small teams, enterprise appli- 
cations are large and often require in the aggregate a large 
number of developers. Development architectures must be 
constructed in such a way as to support sometimes hundreds 
of usees with many, sometimes hundreds of thousands of 50 
development artifacts and their relationships with each 
other. 

All of the major software development tool providers (Le. 
IBM, Microsoft, Oracle, Unisys, etc) have announced 
repository strategies. These repository strategies are much S5 
more comprehensive then the proprietary repositories that 
are represented by a source tool repository such as in Clear 
Case for source code or the proprietary repositories shipped 
with Case Tools or development environments like Envy 
Developer and Forte. Hiese repositories allow for infonna- 60 
tion to span tools and strive for integration between not only 
tools provided by a single vendor or from a host of third 
parties as well. Many case tool and IDE providers have 
announced support for this new generation of component 
repositories. 65 

The new strategies aU espouse either de facto standards 
(Microsoft's Open Information Model) or eventual con- 
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formance to a repository strategy (OMG*s Meta Object 
Facility — MOF). These repositories, although encouraging, 
are very immature and may require a few years to deliver on 
their promises. In the mean time development architectures 
must decide on their own how they may provide the nec- 
essary facilities to promote large team development 
progress. 

Query & Impact Analysis 

Tools are necessary to identify categories of similar 
behavior such as the class hierarchy, where used, senders of, 
implementors of, etc. Today, many environments for C++, 
Smalltalk, Visual Basic & Java provide robust browsers with 
this comprehensive functionality. Additionally case tools 
also provide search capabilities. Unfortunately every tool 
uses a different method for finding artifacts, such as text 
searches for documents, menu provided searches in case 
took, and where used and senders of within browsers. 

As mentioned in an earlier section many of the language 
based IDEs provide sophisticated browsers and explorers 
that allow for searches for "where used" and "senders or for 
messages and objects. These facilities arc extremely impor- 
tant in component leveraged architectures. They allow 
developers to more effectively look for things to reuse rather 
than always re-inventing what they need. One important 
practice to help the searching process is naming standards. 
They should be put in place early in the process to enable a 
principle ParcPlace was fond of calling, "the principle of 
least astonishment". Because of polymorphism developers 
become very agile in locating classes and methods because 
their interfaces are so common like all objects responding to 
the "to String( )" method. 

One of the problems in current development architectures 
is the redimdancy of the facilities. For example, rather than 
be able to rely on the repository where the information 
should be stored in a common location developers may 
search in Rational Rose and in the source code manager for 
references of a given type. 

One way to mitigate this issue is to publish information to 
a common location to make it accessible to everyone 
through a common interface, preferably a web browser. 
Tools like JavaDoc and Microsoft Word (which can trans- 
form documents into HTML) make it possible to leverage 
the web server's index server to locate artifacts from various 
locations. This practice is being more widely adopted, as 
shown by the release of IBM's JCentral tool. 
Asset Catalog (Reuse) 

One key improvement in component-based development 
from traditional development is the use of components to 
assemble solutions. This is very different from libraries. 
Because of the reflective nature of components, runtime 
binaries can be dropped into the development environment, 
their interfaces exposed and then integrated into the current 
solution space. Tliis is done through the Java RefiectioD 
mechanisms within class files and type libraries in the 
Active/X world. 

Currently reuse tends to be at entire source code branches 
rather than component-oriented. This has been provoked by 
poor version support in most development environments and 
tools inadequate for managing the assembly and configura- 
tion of components into solutions. Some component man- 
ager tools that are being released onto the market today 
support either the ActiveX or JavaBean component models 
but its not clear how they may be received, used and 
integrated into development and design environments. 

To maximize reuse requires the assembly and configura- 
tion of run-time components in addition to being able to 
construct new components as part of the software construe- 
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tion process. A new breed of tools supporting black box 
reuse referred to as "Component managers" should be 
considered one of the primary tools provided with the 
environment to 1) support transformations between tools 
where this may continued to be a requirement, 2) enable 5 
component views of reuse allowing configuration from both 
run-time and development components and 3) give compo- 
nent developers security features preventing users from 
modifying and/or reusing certain components if they desire. 
It requires the abiUty to categorize components and search 
components according to property descriptions in a way that 
can be ascertained without the viewing of source code. 
Code Generation 

In the past code generation was crude, had to be 
customized, and was hard to keep synchronized once source 
code was emitted. This awkwardness was caused by other 
related factors Hke the lack of a common information model, 
little coupling with the IDE and no common repository 
sources. In addition, the ability of the CASE tool environ- 
ment to comprehend the run time environment was poorly 
supported in most tool environments. The most damaging 20 
problem is the failure of CASE tool providers to "own" the 
code integration and generation produced from the model. 
Some of the efforts to integrate with IDE*s via Add-Ins are 
a step in the right direction but, some key issues, such as 
identity integrity across multiple environments, have not yet 25 
been addressed to ensure its success. 

That being said, code generation via case tools at the 
structural level can greatly increase the productivity of a 
team when a rigorous model is adhered to in mapping the 
domain model constructs to code or schema in the target 
environment. Two areas have been used to some degree of 
success from component engagements 1) generation of DDL 
from object schema — the domain model and 2) generation 
of the object structure or domain model to the target lan- 
guage. 

One analogy has been made with Layout Managers or ^5 
Screen Builders. A decade ago people were comfortable 
with coding windows by hand. Some even felt that form 
designers were too constraining and got in the way of 
developing a really nsable interface. However, no one today 
would think of generating forms by coding them by hand. So 40 
with the standardization of UML and the maturing of object 
model semantics developers should be reticent to code class 
structures by hand. Oracle refers to this as "one source of 
truth". A change to the class structure in the source code is 
a change to the model and vice versa. 45 
Desktop Tool Integration 

Desktop tools today generally include an office suite, 
drawing tools, case tools and more recently, a web browser. 
For example, one might find a tool selection like Microsoft 
Office for documentation, Visio for custom deliverables, so 
Rational Rose for models, and Internet Explorer for viewing 
HTML versions of the documentation. VBA has become the 
glue for extending and connecting the information between 
these tools. Other strategies have included using Notes as a 
repository for all of the deliverables that users could access 55 
information. 

ODM has many predefined deliverable templates that are 
targeted towards this suite of tools including Word, Excel 
and Visio templates. Often times management under- 
estimates the start up cost of integrating the tools in such a 60 
way as to improve Hxc flow of information between phases 
and for ensuring that information is published to the team in 
a way that is accessible and plentiful. However project 
experience teaches that this investment can yield many 
returns down the road if the development architecture 65 
includes processes and infrastructure to support this flow of 
information. 
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This desktop tool integration strategy needs to take into 
account the comprehensive approach used by the configu- 
ration management strategies. In other words, relevant docu- 
ments need to be associated with the components and 
business processes they update so that key stakeholders can 
subscribe to alarms that may make them aware of when 
sections of documentation need updating. This process may 
help ensure that the publishing model is dynamic and 
current. 

Many Users and Multiple Locations 

Solution Centers and engagements often have many users 
and multiple locations involved in solution delivery. It is 
very important for development architecture teams to solve 
the problems of concurrency within tools and ownership 
across locations. Strategies need to be developed for how 
components may be exported and imported, and supported 
across locations. In addition, an approach for receiving 
feedback for improvements needs to be established. Most 
projects have found that ownership is even more important 
in a distributed development environment. Hiis allows for 
the using of master/slave assignments on components and 
dictating either who is allowed to make changes to the 
component or who is responsible for merging changes. As 
one technologist from Sun stated, if distributed development 
is not managed carefully it can be like herding cats. 
Summary 

Although there are new challenges with development 
architecture in a component environment there are also 
additional opportunities for increased productivity. A team 
that understands the additional considerations may weigh 
the opportunities that tool integration can bring to the project 
against the practical gap in the market place and customize 
their development architecture accordingly. Wise planning 
and a clear understanding of the strengths and limitations of 
the tools available to a team may contribute greatly to the 
success or failure of a project. 
Managing Performance 

Component-based technology is often sold on benefits 
such as reduced maintenance, increased reuse, or flexibility 
to absorb change. Performance, on the other hand, is usually 
viewed as a significant drawback. However, resilience to 
change and performance do not have to be mutually exclu- 
sive. 

Component Technology Can Enable Better Performance 

Component-based systems have advantages that can actu- 
ally enable better performance — but only if proper design 
techniques are used. This chapter discusses the correlation 
between performance-tun ability and a well-designed 
component-based system, and the implications ttus has for 
project management. 

The timing of when to address performance may initially 
appear trivial "Design performance in from the start" is one 
often-repeated rule. The opposing viewpoint is expressed by 
computer scientist David Knuth who said, "Premature per- 
formance timing is the root of all evil". Timing when to 
address performance is acmally a complicated management 
issue. The competing forces and their possible resolution are 
discussed further below. 

Define Performance Goals in Terms of the Business 

An old saying goes, "Cheap, fast and good — I'll give you 
two out of three". Many of clients may react negatively to 
this philosophy, because they would certainly like excel- 
lence in all three areas. Yet, the fact remains that difficult 
tradeoffis exist between performance, quality, and the cost of 
the system. For example, no one intentionally designs a slow 
system. Thus, it is critical to define performance goals in 
business terms based on cost/benefit analysis. 
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Consider service level agreements for online planned and conducted at the outset of the project. These 

performance, which are often based on the average wait time measures are important, because intuition may often be 

between screens. This makes sense in a technical environ- wrong as to where the problems lie. 

ment using 3270 display devices. However, this may lead to In addition, the technologies that make up the foundation 

poor business decisions for a non-modal, windowing GUI. 5 of a component architecture may be new and unproven. To 

A GUI may support a more rich set of processing than a minimize risks, look for a reference appUcation that is 

3270-based design. This can result in response times much ^^^^ ^ complexity and size. If a similar application can^ 

slower per window; however, the time for completing the ^o^^^^' ^^y,^ necessary to develop a proofof- 

business transaction such as a customer order may be conceptprototypefor the arcbtecturc^ Such aprotot^ 

ec^uivalentorevenle.^^^^^^ ao ^^^J^^^^^^ 

equivalent level of wmdow-to-window response Umc may perfonnanc^ is Balanced Against Encapsulation and Soft- 

simply not make economic sense. Thus, the reqmrements ^^^^ Distribution 

should be based on how efficiently the system completes the Performance is Frequently Balanced Against Encapsulation 

pure busmess event, encompassing potentially multiple Software Distribution 

windows, rather than a more technical measure of window- 15 ^s with any system, there are design trade oflfe that can be 

to-window navigation. made to achieve better performance. With component-based 

Measure Performance systems, some of the most significant performance trade oSs 

Any effort to effectively address performance requires are made against encapsulation and software distribution, 

thorough measurement capabilities. Tliere are two reasons The encapsulation of data forces applications to access 

for this. First, the team must understand where the specific 20 data through a component's interface. Unfortunately, cncap- 

risks reside, before they can effectively attack them. Is the sulation may many times result in excessive messaging, 

application I/O or compute bound? Is database or network sometimes across a network, between components. Thus, 

I/O a bigger issue? Are there obvious bottlenecks? These are performance can often be improved by breaking encapsu- 

all key questions. lation to directiy access data. 

Performance Metrics Focuses Attention and Provides Con- 25 Software distribution is often simplified by utilizing cen- 

fidence tralized application servers. However, a centralized 

Second, just the simple act of measuring and tracking approach may result in diminished performance due to the 
performance focuses attention in a positive way. Tools such network messaging. Performance can often be improved by 
as language profilers and memory-leak checkers are critical. distributing software closer to the point of usage. 
A rich set of tools can give the team more confidence in the 30 Selecting the right balance between performance, soft- 
quality of their development and technology. ware distribution, and encapsulation is not easy. Achieving 

Confidence is particularly important to object-oriented the right balance may be driven by system's requirements, 

and component-based systems development, because a deli- Performance T\ining Can be Deferred with Object-oriented 

cate balance is necessary between addressing performance Frameworks 

risks without detracting from good object-oriented design. 35 Object-oriented Frameworks Enable Performance Tuning to 

For example, fear of messaging overhead may lead devel- be Deferred 

opers to avoid altogether factoring behavior into smaller Smalltalk columnist and consultant Kent Beck espouses 

methods and objects. Yet, such factoring is critical to appli- the philosophy "Make it run. Make it right. Make it fast." At 

cation reusability and quality. a glance, this advice may seem counter to the previous 

Fear of Object Messaging Overhead Can be Overstated 40 recommendation to address performance risks early, 

Apotential source of misunderstanding is equating object However, they do not have to be mntually exclusive. An 

messages with network or operating system messages. application should be prototyped — ^i.e., made to run, early to 

Actually, object message sends are often more comparable address broad architecture performance risks. Later, proper 

to function calls, albeit slower. And the overhead of message design should be the focus before performance, because a 

sends compared to fiinction calls can be unimportant com- 45 well-designed application enables more productive perfor- 

pared to the application I/O. That is, most applications are mance tuning. Optimized code is simply very difficult to 

I/O bound, not compute bound. On the other hand, it is maintain. And prematurely optimizing code may incorrectly 

important to imderstand the firequency of component mes- assume what problems are most important, thus wasting 

saging since it may cross network or process boundaries. effort. 

Thus, when looking at messaging characteristics it is impor- 50 Object-oriented system development, in particular, allows 

tant to distinguish between component messaging and for a deferred attention to performance. The component 

object-messaging, design goal of encapsulating implementation details tends to 

Address Architecture Performance Risks Early lessen the impact of major change to the application. This 

As with a traditional client/server system, performance allows sweeping changes to be made late in application 

risks should be addressed early. Performance requirements 55 development. FIG. 53 is a diagram which illustrates a graph 

often have a severe impact on the technology architecture 5300 of resilience to change. 

including the infrastructure design and the platform systems This graph illustrates the belief that through a good 
software and hardware. For example, the architecture team object-oriented design, changes related to performance tun- 
may need to decide whether to use messaging, remote ing may be made much later in the development lifecycle 
procedure calls, or shipped SQL statements for distribution 60 than would generally be possible with traditional stmctured 
services between client and server. Performance may also design. With an emphasis on good object-oriented design, 
impact fundamental platform decisions such as the choice of the degree of radical change possible late in development is 
language, DBMS vendor, operating system, network, or surprisingly high. 

hardware configuration. Non-object-oriented Systems Should be Performance TUned 

Usually these parameters cannot truly be understood 65 Throughout Development 

without constructing a benchmark prototype. In cases where When components are not built using object-oriented 

the underlying platform is affected, the benchmark should be frameworks, it may not be as feasible to defer performance 
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tuning. Without frameworks that provide a well-layered and 
factored architecture, it may not be possible to make small, 
localized changes that result in dramatic performance 
improvements. Instead, it is better to performance tune as 
the system is being built so that there is time to make 
changes. Furthermore, it becomes even more important to 
establish design guidelines early in the project so that 
detailed designs can be reviewed against them. This can help 
ensure that performance problems are avoided before com- 
ponents are implemented. 
Leverage Points 

The value of reuse is frequently perceived as "less to 
code". While often true, a sometimes overlooked, more 
valuable aspect is "less to maintain". This is notably sig- 
nificant when performance-tuning a system. It is generally 
worthwhile to spend more time upfront determining how to 
reuse existing components than it is to spend less time 
developing a new solution. Similarly, it is usually more 
worthwhile spending more time generalizing a component 
so it may be reused than it is spending time to develop a 
specialized solution. 

A Leverage Point is Factored Out Behavior that Enables 
Leveraging Global Performance Gains 

A leverage point is processing common to multiple com- 
ponents which may be factored out and reused when needed. 
Id performance tuning, these points are identified, profiled 
and tuned, thereby leveraging any performance gains against 
all components which use them. In general, the less actual 
processing an application-specific component (i.e. non- 
architecture) performs indicates the more performance 
leverage may be gained from it by tuning architecture 
processing. 

For example, a business event controller class in a system 
must somehow specify the relationships between its relevant 
business components and the widgets which may interact 
with them on the application window. There are two fun- 
damental approaches in specifying these relationships. The 
first is for an initialization method to be invoked in the 
controller which may perform the processing required to 
define these relationships. The other is for that business class 
to specify the bare minimum information required to infer 
these relationships such that a common architectural com- 
ponent can perfonn the actual processing required to define 
the relationships during runtime. 

ITie latter approach provides a leverage point for perfor- 
mance tuning the initialization of the window. The process- 
ing may be tuned to use a more efficient algorithm; the 
results of the initialization may be cached during application 
packaging and read during initialization; or, efficient initial- 
ization methods may be generated and maintained automati- 
cally from the information by a code generator once it 
becomes clear what the most efficient implementation is. In 
any case, the flexibility provided by this leverage point 
allows many more possibilities to be considered during 
performance tuning. Note that all three optimizations could 
be achieved without manually visiting a single of perhaps 
hundreds of windows which share the initialization process- 
ing. 

TTie pursuit of leverage points must be considered in 
every ardiitectural design decision, and followed with dis- 
cipline in application design. 

Communication Via Interface Definitions — Specify What 
Not How 

On a component-based project where the development 
should reuse extensively, the name of a component and its 
methods are perhaps the strongest medium of commimica- 
tion between the original developer and a developer inter- 
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facing with, or maintaining that component, A fundamental 
grammatical naming standard is the means to ensure clear 
communication between developers. This standard must be 
well-defined, strongly enforced, and supported by leader- 
5 ship. 

A weak standard of interface definition often results in 
code reqmring extra processing which could be avoided by 
making assumptions based on a strict interface definition. 
Performance tuning is easily complicated by generic inter- 
10 faces supported by vague assumptions. Redefining such 
interfaces late in development is often prohibitively expen- 
sive relative to the low cost of clear initial interface defini- 
tion. 

An example of a poorly-defined interface is a method 

IS definition which may accept several unrelated types as its 
parameters. The result leads to type-checking of parameters 
and decreased flexibility in tuning the implementation of the 
method. The strong definition of interface parameters allows 
fundamental assumptions to be made in timing the imple- 

20 mentation of the interface. 

A grammaticafly-based naming standard differentiates 
between methods that do versus methods that get. In a 
traditional approach, procedures or functions do routines 
and algorithms. The unique blend of data and behavior in 

25 component-based development, on the other hand, allows 
components to collaborate, asking each other for data, as 
well as directing each other to perform processing. This 
reqmres the addition of nouns and the inclusion of verbs to 
the vocabulary of interface definition. That is, the interface 

30 should specify what, not how. 

For example, if a customer component provides a public 
interface that allows another component to ask it to query the 
database for its credit profile, a common mistake is to define 
a method getCreditProfile or retrieveCreditProfile in cus- 

35 tomer. If, however, performance tuning reqiured caching the 
customer may already have the credit profile. This would 
leave development with the choice of either changing the 
method name in all referencing components, or create docu- 
mentation to explain why the method getCreditProfile didn't 

40 really get anything, but just provided access to another 
component. 

This example illustrates the importance of naming to 
ensure encapsulation. The implementation changes required 
to achieve radical performance improvements are feasible 

45 only through diligence in the pursuit of encapsulating imple- 
mentation. Along with good design organization, clear inter- 
face definition is key in achieving valuable tunability. 
Limit Knowledge of Data and Object Relationships 
Developers with structured programming experience 

50 often tend to perceive objects as data, manipulating them 
within the context of objects, effectively distributing behav- 
ior associated within components amongst all the objects 
which interact with it. This becomes very difficult to per- 
formance time due to the combination of duplication of 

55 code, and the wide impact any such tuning could have on 
application classes. A much greater degree of performance 
tuning can be achieved when object responsibilities are 
respected and objects or collaborations of objects can be 
tuned in isolation with minimal impact to their embedded 

60 system. 

A simple example of "data-ifying" objects is when object 
A manages a group of other objects, yet other objects ask 
object Afor its managed objects and manipulate them freely. 
GeneraUy loop iterations are prime candidates for significant 
65 performance improvements. If the iterations are distributed 
over every object that interacts with object A, little perfor- 
mance improvement of component A may be gained without 
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high impact. By restricting interfaces such that only object dead. Today, one is wiser about including batch in the scope 

A may iterate over its own managed objects, the iteration of both architecture and application efforts. One also finds 

code can be tuned with little impact outside object A. that many of the principles and concepts that applied to 

Performance improvements can always be identified. The batch twenty years ago also apply today. 

difSculty is in the cost of actually implementing them. The 5 In general, batch slfll has the following fundamental 

strong pursuit of encapsulation allows bottlenecks to be characteristics: 

identified more easily (Le. in one place), and tuned with Scheduling— Services are required to manage the flow of 

minimal impact processing within and between batch jobs, the interde- 

Leverage Functional and Technical ISmmg pendencies of appUcations and resources as well as to 

Hiough tuning of a component-based appUcation can be lo provide mtegration with checkpointing fadUtics. 

deferred until late in development, eventually it must be Restart/Recovery— Batch jobs must be designed with 

done. At this point it is important to realize the difference restartability in mind. This implies the need for a batch 

between functional tuning and technical tuning. restart/recovery architecture used to automaacaUy 

Functional tuning involves a combination of cognitive recover and re-start batch programs if they should fail 

and measured tuning. It consists of looking at the functional 15 during execution. 

design of a component and determining which portions of Controls — Run-to-nm and integrity controls are still 

processing can be deferred, cached, etc. It demands a required to ensure that all data is processed completely, 

developer who is functionally knowledgeable about the Reporting — Services are required to handle configurable 

dcsiied behavior, whether it be architecture or application. It report creation, distribution, printing and archiving, 

often results in reorganizing or redesigning portions of code. 20 These services are typically not provided through com- 

The performance gains realized during functional tuning are ponent technologies. TTiey can be provided by third -party 

generally the most significant gains. products or custom implementations. 

Technical timing is a lower-level approach to tuning, How is batch different in a component-based system? 

developing more efficient techniques to achieve the same A system's batch architecture can be easily overlooked 

functionality. Technical tuning demands a developer who, 25 since it is not a part of the system that is visible to end-users, 

though not necessarily intimate with the functional Regardless, it is critical to design components with both 

requirements, has a strong familiarity with tricks and tech- on-line and batch requirements in mind. Combining both 

niques of the development platform. It can involve better use sets of requirements is necessary to ensure that your com- 

of memory, language idioms, base class modifications, etc. ponents can be used in both enviromnents. This will allow 

Technical tuning should require little or no changes to 30 the batch programs to act as just another client to your 

application code, and narrow changes to architecture. components. 

Opportunities for performance tuning are found both in In addition, since many on-line systems are expected to be 

bottlenecks and in distributed inefficiencies. There are gen- available on a 24x7 basis, there may be a limited window 

erally many tools available in detecting bottlenecks. Dis- available for exclusive batch processing. This requirement 

tributed inefficiencies are usually more difficult to identify 35 can have a tremendous impact on your batch architecture. In 

with tools. Whether performance optimizations are realized these environments, it is necessary to design batch programs 

through cognitive analysis, or tool-assisted profiling, it is that make efficient use of resources and have a low impact 

important to measure the gains against a baseline perfor- on on-line users, 

mance level. A component-based batch architecture must support batch 

Few performance improvements are gained by eliminat- 40 programs that read transactions that are really messages, 

ing completely useless code. Gains are usually achieved by These message transactions are read either from a flat file or 

trading speed for size, or chronologically reorganizing pro- fi'om a database. The program must then locate the compo- 

cessing. Improvements in one area may weigh in a different nent for which the message is intended and pass the message 

area. For example, runtime processing is often sped up by to that component for processing. In many cases, these will 

increasing initialization time. When making such changes, 45 be the same components that process messages from on-line 

measuring the affected runtime processing is insufficient. It (GUI) applications. The function of the batch "program" in 

is necessary to measure also the areas impaaed to determine this environment is fairly limited. It reads the input 

that the optimization does not push another area into unac- messages, controls the packaging of database units of work, 

ceptable response. and sends requests to the business component that performs 

Summary 50 the actual business logic associated with the messages. 

Performance is an acknowledged risk in developing com- Batch architectures usually "commit" on intervals that are 

plex systems with today's maturing component technolo- designed to optimize database resources. Thus, it is impor- 

gies. To reduce risk and uncertainty, it may be necessary to tant to design components that can participate in a logical 

develop prototypes that validate the architecture approach. unit of work that is controlled outside of the components. 

When components are built using rich object-oriented ss How do the patterns in this section help? 

frameworks, it is possible to tune a component-based system The patterns described in this section represent some 

more effectively and later in development, than its structured initial attempts to capture basic concepts that are useful in 

counterpart. Other more traditional approaches to the design of a component-based batch architecture. They 

components, may require tuning throughout the develop- are by no means exhaustive but represent building blocks in 

ment cycle. 60 a complete solution. , 

Base Services (10l20) The Batch Job pattern describes a method -of structuring 

Batch processing is used to perform large scale repetitive batch components so that common architectural services are 

processing where no user involvement is required. Batch implemented unifonnly across all of these components. In a 

support is an often overlooked area in architecture and way, this is the component-based analog to the concept of 

component design. When first client/server and then com- 65 shell designs and skeleton programs which have been a 

ponent technology hit the scene, the emphasis on GUI and recurring feature of robust batch architectures for many 

communications was so strong that many thought of batch as years. 
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Hie Batch Unit of Work (BUW) pattern, oa the other 
hand, represents a method of structuring the work to be 
processed by the batch components so that it too can be 
treated uniformly by all components. An abstraction such as 
this forms the basis for distributing batch woridoads in a 5 
number of useful ways. It also enhances the capability of the 
architecture to support evolutionary change. 

ITie Processing Pipeline pattern describes a way of struc- 
turing batch activities so that they can be easily reconfigured 
as processing requirements change. This pattern directly jq 
addresses the issnes of scalability and reuse in a component- 
based batch system. 

The Abstraction Factory pattern has a much broader 
applicability than just batch systems. It represents a way to 
encapsulate diversity such that only those parts of the system 15 
that need to understand the difference between two objects 
have to deal with those differences. To use a typical batch 
example, a file is a file is a file. Only those components that 
require knowledge of the contents of a file should need to 
deal with those contents in other than a very generic way. 20 

What are some other considerations in developing a 
component-based batch architecture? 

Because batch processing executes on a server and 
requires limited user interaction, many of the services used 
for on-line architectures are not needed. For example, the 25 
services used for distributing components — naming, distrib- 
uted events, bridging, trader, etc — are not needed for a batch 
architecture. In fact, the interfaces that encapsulate compo- 
nents and provide location transparency can add significant 
overhead to a batch architecture. To avoid the expense of 30 
unnceded services, the component stubs can be wrapped 
with a layer of indirection that short-circuits the normal 
distribution mechanisms. This will provide performance that 
will approximate local function calls. 

Typically, business objects have to be instantiated fix3m a 35 
relational database (RDBMS) before the batch application 
can make use of them. This extra overhead is a very real 
concern. It is an unfortunate fact that in many ways the more 
"object-oriented" your design is, the worse it fits into the 
relational paradigm of rows and tables. For one thing, these 40 
designs tend to have lots of objects with embedded instances 
or references to other objects. And the primary reason that 
such designs have RDBMS performance problems is that in 
the database, resolving such an object relationship requires 
joins or recursive queries. When mapping from your object 45 
model to the RDBMS, there is a tendency to "normalize" 
your object over many tables, and the performance can 
easily plummet. 

Is eflldent component-based batch hopeless? No. But if 
you have stringent batch performance requirements, you 50 
may need some ^ecialized design. There are several tech- 
niques you can use to improve your batch speed. 

Reduce (eliminate, if you can) batch. This may sound 
simple and stupid, but is often overlooked and is by far 
the cheapest way to improve your batch yield. Lots of 55 
reports can be obtained on-line, lots of them are not 
useful or used, "trigger transactions" can simply 
become spawned sub -processes that run in the 
background, same for printing bills, the only thing that 
must be done in batch is a database reconciliation, 60 
which requires a time window with no other activity. If 
you can engage in discussions for eliminating batch, by 
all means do. 

Pool (recycle) objects. Each time you dispose of an 
object, instead of destroying it put it in a pool of 65 
recyclable objects; and every time you create a new 
object, look in the pool to see if there is one that can be 
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recycled. Keep separate pools for each class of objects. 
Allocating objects is a lot more expensive than one 
tends to think, and recycling can improve your batch 
performance dramatically without affecting your 
design. 

Cache and sort This technique is well known to "tradi- 
tional" batch designers, but it is so obvious that they 
don't even think of it. However, it has a correspondent 
object implementation. Keep a small cache of objects 
you have just read from the database. Most of the times, 
one instance of each is plenty. Whenever you need to 
access an object on the database, look to see if it is 
already in the cache. If not, read it and put it in the 
cache too. Encapsulate all this logic in a technical 
"Table" object — not in the business objects. At the 
same time, organize the processing of your data in a 
sequence that maximizes cache hits. Again, this tech- 
nique does not affect your "business objects" design. 
The processing cost of this technique is so low that you 
can keep it enabled also for on-line, thus simplifying 
your technology architecture. 
For some appHcations, an LRU caching policy might not 
be the right choice; a more complicated scheme with mul- 
tiple cache levels might be necessary. For this reason it 
would be best to make the caching policy itself be an object 
(consider the Strategy pattern for making an object from an 
algorithm) so you can change the policy on demand. 
Cache operations and accesses. One of the reasons 
component-based batch performs so poorly is due to 
the fact that, in order to maximize modularity and 
preserve encapsulation, a lot of operations are per- 
formed redundantly. For instance if a balance is imple- 
mented as a calculation, and if it is needed by six 
different objects it is recomputed six times. These 
situations are very easy to identify with a performance 
monitor that tells yoxi where the program spends most 
of its time; it is not uncommon to find that most of the 
time is actually spent in very few methods. For these 
methods (and only for them!) cache the result in an 
instance variable. Every time the method is invoked, 
check if the instance variable contains an answer: if not, 
compute it and store it there; if yes, just return it. Of 
course, eadi operation on the object that invalidates the 
result of the computation must invahdate the cadie too! 
This technique has a very small impact on your object 
design and typically leaves the interface undianged. 
Cache objects. Topically, this would involve leaving 
recently referenced objects instantiated in memory for 
some length of time after their last use. Then, if the 
object is accessed again, you check the memory- 
resident cache before re-loading the object from the 
DBMS. Usually you would construct this cache as a 
hash table keyed by object ID, and use a LRU policy to 
keep the cache size manageable. Expect degraded per- 
formance if you do anything to destroy the utility of the 
cache. For some applications, LRU might not be the 
right dioice; a more complicated scheme with multiple 
cache levels might be necessary. For this reason it 
would be best to make the caching policy itself be an 
object (consider the Strategy pattern for making an 
object from an algorithm) so you can change the policy 
on demand. 

Make use of "lazy*' or "deferred" loading. That is, don't 
do a "deep" instantiation until you know you're going 
to use the associated parts of the object. Instead, load 
selected sub-objects only when first referenced This 
can save on memory overhead as well as DBMS access. 
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In some cases you can use a hybrid strategy: do a language. As an option, the located concrete object may also 
"shallow** instantiation by default, but provide the be inserted into the abstract object. With this option, the 
client program with a way to build the complete object abstract object may operate as a handle, 
on demand to provide more deterministic performance. ^ desirable to separate concerns between architecture/ 
One thing to be careful of with this approach is that if 5 framework and implementation details. One way to do this 
you really do tend to use most parts of the object during ^ ^^^^^^^ ^^^^^ polymorphism, using an abstract 
high-volume processmg, loading it in piecemeal can interface to a concrete object which implements that inter- 
actually worsen the performance; because of the over- jj^^^ ^j^gj^^ ^^^te these concrete instances and 
head of maintaining the load state and because of the manipulate them within a framework while preserving the 
smaller DBMS transactions sizes. These techniques 10 framework's independence? 

have a very small impact on your object model. In any complex information processing system, there will 

De-nomialize your database where possible. lypicaUy ^e a variety of different types of information, with a corre- 

when one does object-to-relational mappmgp, one tends spending variety of actions which must be taken to process 

to make every unique object type a separate table. This information. One of the dif&culties in this task involves 

is best from a design perspective. But in cases where 15 taking an information source and creating an appropriate 

you know you have a fixed set of "private" associations ^^^^^^ representation for it. 

(meaning physical apegation with no possMity of .^^ ^ ^^^^^ ^^^^^ ^ 

shared references), then fold that sub^^^^^^ data into ^ sv^{ch/cas^ statement, where each case deals with one 

the enclosing object s RDBMS table. I s not pretty, but information types. Tlie switch/case approach leads to 

itcansavelotsofextraloa(hngtmie.Also,lookatways 20 components that are very difficult to maintain, extend, 

to do aggregate loads based on some unique object ID, ^^^^ ^ procedural programming 

For example, if you have coUecUon-yalued sub- ^ ^^^^j^ ^^^^ ^^^mely difficult to 

components msert^e object ID of the enclosing object ^ ^ dependencies so that the details depend on 

m tiie sub-object tables and do aggregate loads m code ftamework and not vice-versa, 

rather than doing a "pomt-of -use instantiation for each 25 njuu^t.- - • j u u *u j 

. 1 .u *• • *• u With this mmmd, some alternative approach must be used 

one separately. Of course, these optimizations can have 1 • * .,1 n r 1 . i_ ir 1 • r 

^ . / ^ t ' \ u- * J 1 which will allow a framework to handle multiple informa- 

a more substantial impact on your object model. ^ . i_ j * 1 

„ , . w„ ' r r . tion types m a way which encourages good style, 

Consider makmg "bght versions of some of your objects. ^^jularity, extensibility, and framework independence. 

That IS, for performance cntical situations, create alter- / . i *u • ^ c a * 

^ • 1 ^ r * - i_- * it. i Therefore, one transforms the various types of raw data 

nate implementations of your business objects that 30 . ■'"'^^'^^"^^^ • . r . l- . . n * 

J 1W1. 1- £ . 1 1.* * V mto a corresponding variety of concrete object types, all of 

don t have all the baggage of the first-class objects. Yes, t.. . i. i_ . 4^^.- : c 

^, . , 1 J ^ J. a- 1* * • * • n * r which share a common abstract mterface. This transforma- 

this can be ugly and more difficult to mamtam. But for .„ . 1 * j ^ * 

. , L^"^ 1- • i tion wul be encapsulated within an Abstraction Factory, 

many batch processing apphcations you might find that . . ^ , , . . 

you can drop a lot of the (persistence-related) com- P™^y "^^^^^^^ Abstraction Factory is: 

plexity of an object without affecting the batch pro- 35 "abstractType produceForKey(key)" 

cessing at all. Then create fast hand-tuned routines to where "abstractiype" is the type of the common abstract 

instantiate the "light" objects from the database. interface, and key is a piece of information which identifies 

As can be seen, there are a lot of opportunities for the appropriate concrete type. (This could be the same piece 

improvement in component-based batch performance. of information used in the switch/case statement; there could 

However, in order to manage risk early, remember that the 40 be a variety of ways to get it). When this method is invoked, 

areas in which you will have trouble are those in which batch the Abstraction Factory consults its internal mapping and 

excels (predictability, repetitiveness) and component-based creates an "empty** object of the proper concrete class. The 

design trades off performance for flexibility and encapsula- factory then casts the concrete object into the abstraction and 

tion. Message overhead and similar language related issues returns it to the method's client This client (a framework 

are unhkely to be critical. Obviously, before doing any of 45 most likely) will then instruct the abstraction to initialize 

these things you should do some serious benchmaridng to itself from the incoming data stream, 

see where you're comingup short on performance. Often the ^t the end of this process we have an abstract handle to 

overhead comes from surprising places. Don't twist your ^ concrete object which a framework may then manipulate 

object model all out of shape without first having some solid genericaUy. 

performance measurements. 50 ggjjggtg 
Abstraction Factory 

HG. 54 illustrates a flowchart for a method 5400 for Software Quality Exploiting this pattern can allow us to 
providing an abstraction factory pattern. Data is received avoid one of the major pitfalls of procedural 
and transformed into a plurality of concrete objects in programming, the switch/case statement. Done prop- 
operations 5402 and 5404. Each of the concrete objects is 55 erly you get better modularity, testability, maintenance 
associated with an abstract interface in operation 5406. A extensibility. 

map of the association between the concrete objects and the Frameworks. The layer of abstraction introduced allows 

abstract interface is created in operation 5408. In operation us to build frameworks which follow the open/closed 

5410, when request is received which includes an identifier principle, that is to say, they are open to extension by 

for one of the concrete objects and an identifier for the 60 the addition of new concrete types, but are closed to the 

abstract interface. The map is consulted to locate the con- necessity of risky and costly modification. 

Crete object that has been identified in operation 5412. An Implementations of this pattern will vary widely depeiid- 

abstract object is then created that corresponds to the located ing on the selection of language. For example, in C++ a 

concrete object in operation 5414. generic factory, based on templates can be constructed, and 

The identifiers may be included with a single request. In 65 key — concrete type pairs can be registered to the appropriate 

another aspect of the present invention, the abstraction instantiation of the class. This might require manual coding 

factory pattern may be written in a C++ programming in other languages. The key interfaces, however arc: 
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Abstraction Factory: Therefore, represent each type of batch job in the system 

Abstractiype produceForKey(key) as its own class. An abstract class (BatcbJob) will exist from 

Abstract Type: which all specific types of batch jobs will derive from. The 

init(some data stream) abstract BatchJob contains data that all batch jobs require: 

The Abstraction Factory can be fully coded in C++. It is 5 name, current status (pending, started, finished, deleted), 

very re-usable as it stands. In addition, it has been messages encountered during its run, various times 

extended to perform "Java Loader-like" dynamic link- (submission start, completion), and a priority, for example, 

ing if the proper code cannot be found already within I* ^^^^ provide some default behaviors mduding 

the factory rxmnmg the job and logic to execute before and after the run. 

Factory, the wcU know pattern from Gamma, et. al lo iH^trates a class diagram of the batch job 

BUW, in which the objects created by the factory can be ^^Jf^ ^' . , , - . , i , i- .t 

A^^it ..ruu „-„-^„lii„ ;« / «p Vanous system batch job classes can subclass from the 

dealt with genencally in terms or independence, * rj /ut u ^ rnn j jj *u • -a u * 
^.,,uK;t;*,, r«^^«™«t c«i„ abstract BatchJob 5600 and add their own required attributes 
scalabihty, parallel processing, etc. Component Solu- j u u • a «rj n ♦ » u *^ ■ u a *u 
tions Handbook " ^ ^ and behavior. A Bill Customer batdi job may need the 
Batch Job 15 customer to bill and the time period for 
FIG. 55 illustrates a flowchart for a method 5500 for '^'^ }° TT^ese should attaVutes added to the 
representing a pbralily of batch jobs of a system each with «f *f '=lf^= BillCustomerBatchJob 5602. In addiUon, 
a unique class. In operations 5502 and 5504, an abstract ?°.°f=te class needs to supply the actual logic that the 
class of abstract data required by a plurality of batch jobs is ''^'^l' "'"^ ^'\°'^7t^ T\ P'«V«°'>,f ^^''^ 
provided and a plurality of batch job sub-classes arc defined. 20 ^'f^l' concrete batch job class shou d provide some 
Each batch job sub-class includes batch specific data, and way to start-up all of the Pending jobs in lU class. A class 
logic for processing the abstract daU and the batch specific "^^^ is impUmented on the abstract class to sUrt all 
data upon the execution thereof. Each of the batch job P^ding Jobs. Th^ meAod can be overndden by any con- 
sub-classes is represented with an object in operation 5506. Crete extension of the BatchJob superclass^ 
In operations 5508 and 5510. one of the objects is identified 25 ^P^. T f "^v. ? ^ insUnce as any other type of 
and the logic of the batch job subclasses associated with the "^ject, the batch architecture may then take advantage of the 
identified object is thereby executed. ?™« ^y'*'*'" 'T'"^ ^ *H '^'"^^ 

In one aspect, the data may include a name, a current ^ ^^^^"^ (persistence, trai^action management, error 

status, messages encountered during a run, various times, ^ ^' oggiDg* securi y, e c.;. 

and a priority. In another aspect, the abstract class may 30 

include default logic for running a batch job. Natural Representation. Each type of batch job is repre- 

In an additional aspect, the abstract data and the batch rented by an object. This allows it to interact with the 

specific data may be stored separately. In a fourth aspect, the system in a natural way. 

logic of the batch job sub-classes may be executed by a Extensibility. By providing an abstract superclass, adding 

scheduler. 35 types of batch jobs only require adding a new 

A set of logical operations may need to be initiated concrete class to the system, 

through some "batch" scheduling means. This requires a set Architectural Separation. Batch Jobs that are not imple- 

of common services such as activation, logging, and error mented "inside" the object-oriented environment can 

handling that will have to be appUed across all jobs. How stUl be tracked by the batch job objects. The rest of the 

can these common services be distributed to all types of 40 system is xmaware of the batch job objects, 

batch jobs? FIG. 57 illustrates an object interaction graph of a pos- 

Most business systems today include some sort of batch sible implementation of the example of FIG. 56. FIG. 57 
processing. Batch processing is the execution of a series of illustrates a batch scheduler 5700 which interfaces a 
instructions that do not require any interaction with a user to BillCustomer Class component 5702 which in turn inter- 
complete. Batch jobs are usually stored up during the day 45 faces a BillCustomer BatchJob component 5704. 
and executed during evening hours when the system load is ISO New England energy eXchange. A net-centric inter- 
typically bwer. net system build for managing functions associated 

Once a batch job begins, it continues until it is complete with a competitive energy market. The energy 

or it encounters an eaor. eXchange is implemented in Java across client and 

An architecture that supports batch jobs usually has 50 server components and using CORBA as a communi- 

certain characteristics. It must be able to support checkpoints cations architecture. 

and rollback, restart and recovery, error handling, logging, Batch processes are often highly resource intensive. In 
scheduling, and resource locking. many cases the required throughput demands the use of 
Most systems, including those that are component-based, multiple processors, possibly distributed, to provide seal- 
require this sort of architecture. A difficulty arises when 55 ability. How, then, should one structure one's batch work- 
considering component-based systems though. In a load to facilitate a robust and scaleable system? 
component-based system, the application architecture is BUW 

usually very separated from the business application classes. One of the primary techniques used to achieve scaleable 

In many cases, the business classes and components are built batch applications is parallel processing. There are many 

without regard to the sunounding architecture. 60 different types of parjdlel processing, but the simplest and 

It is expected that the business components will execute easiest to exploit occurs when the problem domain contains 

in some environmental container that will provide many of many independent work items. In this case, the work can 

the architectural services (like batch services). simply be divided among the available processors, providing 

Some natural representation of the batch architecture must nearly linear scaling, 

be developed and transparently integrate with the existing 65 Happily, this is exactly the situation encountered in many 

business components and stiU support all of the architectural batch systems. However, also given the nature of batch 

requirements. processing, the variety among the various work items will 
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likely be large. This of course leads to the need to treat some 
items differently than others, and there goes the nice clean 
scaling model. 

With this in mind, some altemative approach must be used 
which will allow a cleanly scaleable framework to handle 
multiple heterogeneous work types. 

TTierefore, one creates an abstraction which represents a 
batch unit of work. Now the design tension comes in. 
Clearly one common abstraction is easy to parallelize, but 
not very interesting to manipulate due to its very generic 
nature (at least if you're interested in type safety). This 
quickly leads us to design a shallow tree of more interesting 
abstractions, and again one's clean scaling model seems 
threatened. 

TTic key is to treat the work units as top level abstractions 
while they are being routed among processing nodes and to 
treat them as more interesting derived abstractions when 
internal to a node. Treating them as topmost abstractions 
between nodes provides a good lever for robust processing, 
as typical actions like lO/persistence, recovery, auditing, etc, 
can often be treated uniformly for all types. 

Treating work units as derived abstractions while internal 
to a node is achieved by actually creating the abstractions 
within the node. See the Abstraction Factory pattern for 
details on one way to achieve this. 

So are we safely scaleable now? Not necessarily. There is 
still the danger that a given processing node will be pre- 
sented with a unit of work it cannot deal with. Kind of like 
asking a parking meter for a hot pastrami. Hiis situation can 
be avoided with proper workflow, or with sufficient 
structure, a dynamic hTjrary loading version of the Abstrac- 
tion Factory could, in effect, tell the parking meter how to fix 
sandwiches. This of course, has the effect of a one time 
performance hit as the processing node is instrumented with 
Qew capabilities. 

Implementations of this pattern will vary widely depend- 
ing on the selection of languages and technical architectures. 
The key is that the all work units in the system are derived 
from a single abstraction. This abstraction contains key 
interfaces that are appropriate at the workflow level. Derived 
abstractions add interfaces as needed functionally. 

Abstraction Factory, in which concrete objects are created 
by the factory and returned to the Factory's client as an 
abstraction. CSH. 
Processing Pipeline 

FIG. 59 Ulustrates a flowchart for a method 5900 for 
structuring batch activities for simplified reconfiguration. In 
operation 5902, a series of processing steps are prepared for 
performing on input objects being streamed into a batch 
processing system. Each of the processing steps is encap- 
sulated within a filter in operation 5904. The input objects 
are received and processed in the filters in operation 5906. 
In operation 5908, results are delivered firom the filters 
incrementally during the processing of the input objects for 
reducing latency and enabling parallel processing. In opera- 
tion 5910, connectors are utilized for connecting at least two 
filters each having a processing step for creating a process. 
One of the filters is an input filter of the process and another 
of the filters is an output filter of the process. Connectors are 
also used in operation 5912 for coimecting input and output 
filters of different processes for forming a scalable system. 

There may be several instances of a particular type of 
filter ruiming in parallel. A portion of the filters may be 
active and a portion of the filters may be passive. In such a 
situation, the active filters may pull input data and data may 
be pushed into the passive filters. Additionally, the input 
filter of the process may be an active filter and the remaining 
filters of the process may be passive filters. 
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The connectors may perform the steps of acting as a choke 
point for data to be pulled from a filter, connecting serial 
filters defined as independent processes, and/or multiplexing 
to demultiplexing from several filters of the same type 
5 running in parallel. As another option, one of the filters may 
be positioned between the input and output filters of the 
process for translating an output of the input filter into an 
input type of the output filter. 

How do I define a disciplined strategy to structure the 
components performing processing steps within a batch 
system so that the system is cleanly partitioned while 
maintaining performance and scalability goals? 

Often batch processing systems perform a series of pro- 
cessing or transformation steps on input objects that are 
streamed into the system. Implementing such a system as a 
1^ single component is not feasible for several reasons: por- 
tions of the component must be developed by several 
developers, requirements are likely to change and it is 
difficult to cleanly partition the modules resulting in a highly 
coupled system. 
20 Compounding the difficulty in implementing the system is 
the fact that most batch systems must satisfy the foUowing 
challenging requirements: 

Must be able to satisfy extremely stringent performance 
criteria. 

25 The system must scale to meet client's volume. 

The system must be flexible enough to be adapted to 

various contexts. 
These requirements are difficult to meet for any system, 
and batch systems' stringent demands often lead developers 

30 to think they cannot use component technology. Buflding a 
procedural batch system to satisfy the requirements listed 
above may result in a complicated set of modules that are 
difficult to maintain as the system is scaled. By utiHzing 
component technology's ability to manage complexity 

35 through encapsulation, a component-based batch system can 
more easily be defined with clean partitioning than when 
using a procedural paradigm. Defined with foresight, this 
partitioning enables the system to scale to meet difficult 
performance requirements. 

40 Therefore, encapsulate each processing step within a filter 
component. A filter consumes and delivers its results 
incrementally, rather than consuming all of its input before 
producing output. The incremental nature of filters allows 
them to significantly reduce latency and enables true parallel 

45 processing, 

AsuppUer provides the input to each filter, and the filter^ s 
output flows to a consumer. Suppliers and consumers may be 
objects that read files, databases or queues, other filters or 
any type of object supplying or accepting data. In order to 

50 produce a flexibly arranged system, connect the initial 
supplier, the filters and the final consumer with pipe com- 
ponents that are responsible for implementing the data flow 
between adjacent filters. 
As a result of filter processing's incremental nature, one 

55 or more filters, tied together with pipes, define a process's 
Logical Unit of Work (LXJW); i.e., the filters defining the 
steps of the process are sandwiched by the beginning and 
ending of the transaction. Expanding this model, each sub- 
system representing the LUW can be modeled as a filter with 

60 input and output that encompasses the internal filters. These 
filters arc then tied together through the use of pipes to 
represent the system. In this manner, the Processing Pipeline 
pattern offers a consistent way to view the system that scales 
to whatever size and degree of complexity the system grows. 

65 Benefits 

Scalability. Hach filter performs its data processing and 
transformation independently of other filters. By lever- 
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aging off some pipe forms' multiplexing/ 
demultiplexing techniques, there may be several 
instances of a particular type of filter running in par- 
allel 

Partitioning. As a result of encapsulating each processing 
step within a filter component it becomes easier to 
manage the balance between coupling and cohesion 
since there are disciplined and well-defined interfaces 
surrounding the components. 

Flexibility. Since filters make little assumptions about the 
world around them, they can be arranged in any man- 
ner; several filters can be combined together and 
wrapped by a larger-grained filter; filters can be 
dynamically assembled at run-time depending on some 
context, etc. 
Filters 

At a high level, there are two types of filter components: 
active filters and passive filters. An active filter puUs input 
data fi'om its suppliers, processes the data and outputs the 
result to its associated consumer. In contrast, input data is 
pushed into a passive filter, which then performs its pro- 
cessing step and outputs to its consumer. 

Typically a system is defined by an active filter at the 
beginning of the Processing Pipeline, that pTills input data 
from the data source and initiates further processing by 
pushing the data to a chain of passive filters situated down 
the pipeline. Often the active filters are only responsible for 
pulling data into the system, while the core business func- 
tionality is performed by passive filters. 

Because active and passive filters demonstrate different 
levels of pro -activity, it is useful to further break down the 
type of consxmiers and suppliers into four general types: 
push suppliers, pull suppliers, push consumers and pull 
suppliers. These foxir sunple abstract interfaces help segre- 
gate the fundamental, yet disparate, behaviors. Active fillers 
inherit both fi'om PuUConsumer and PushSupplier. Active 
filters' sources inherit from PuHSupplier, and their destina- 
tions inherit fi'om PusbConsumer. Passive filters inherit fi'om 
PushConsumer and PushSupplier. Passive filters' sources 
inherit fiom PushSupplier, and their destinations inherit 
from PushConsumer. 
Pipes 

While filters define the basic processing steps, pipes 
define how to flexibly configure the system. Pipes can-be 
used to connect filters in a wide range of configurations: 

Acting as a choke point for data to be pulled from an 
active filter 

Connecting serial filters defined as independent processes 
Multiplexing to/demultiplexing from several filters of the 

same type running in parallel 
Pipes may use buffering, multiplexing and 
de-multiplexing techniques in order to transfer data between 
filters. Some examples of useful pipe implementations 
include: 

Channeled Pipes. Perhaps the most generally useful form 
of a pipe is based on the CORBA Event Channel object, 
which can connect any number of Push/Pull Siq)pliers 
to any number of Pujdi/Pull Consumers. 

Multithreaded Pipes. Tliese pipes route data to one of 
several filter threads. The data can then be joined back 
to the primary thread on the other end of the filter with 
a demultiplexing pipe. 

Database Queue Pipes. These pipes wrap around a data- 
base queue to enable seamless data transfer between 
processes. 

Hic various command shells enable filter programs to be 
tied together into a Processing Pipeline. 
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Collaborations 

Abstraction Factory. Often filters will need to produce 
new data objects from input but are only aware of the data's 
abstract interfaces. As a result of this generahty, the filters 

5 will need to utilize an abstraction factory to produce con- 
crete objects without knowing their concrete class types. 
Business Logic Service Patterns (1024) 

As is stated in the Component Technology Architecture 
Framework, "Business components are the core of any 

10 application, they represent concepts within the business 
domain. They encapsulate the information and behavior 
associated with those concepts. Examples of business com- 
ponents include: Customer, Product, Order, Inventory, 
Pricing, Credit Check, Billing, and Fraud Analysis." These 

15 are the components that in many cases have been the most 
elusive for reuse but hold the highest promise for attacking 
the cost of development. In this area there are at least three 
targeted categories of business components, Common Busi- 
ness Components, Common Business Services and Com- 

20 mon Business Facilities. 

Common Business Components are those components 
from the preceding list that encapsulate key business con- 
cepts. At one level these components represent cross appli- 
cation components that are common to a plethora of appli- 

25 cations. These include concepts like Customer, Company, 
Account, Shipment, etc. These common components nor- 
malize how basic behavior surrounding common business 
concepts can be normalized. Common Business Compo- 
nents are very concerned about the validity of the relation- 

30 ships they have with other components and ensuring that the 
information relationships are maintained correctly. 

Common Business Services deal with the higher level 
services that abstract out the "Business Unit of Work" or 
more transactional aspects of business processing. Having 

35 components that capture key processing concepts normal- 
izes the processes for handling business events. These are 
services like credit checks, ordering, servicing problems, 
shipping, product selection, etc. They tend to capture busi- 
ness practices and when reused enable a company to increas- 

40 ingly leverage the value of those practices. 

Common Business Facilities are those services that deal 
with areas of more engineering component type reuse. These 
include base common facilities like reason codes, currency 
management, telephone and address manipulation and vali- 

45 dalion of these common business types. 
How do the patterns in this section help? 
The patterns described in this section represent some 
initial attempts to capture basic concepts that are useful in 
the area of Common Business Facilities. They are by no 

50 means exhaustive but represent building blocks in a com- 
plete solution. Both provide tremendous value in solving 
two key challenges which appear on every engagement. 

The Constant Class pattern describes a facility for ensur- 
ing correct data at the attribute level. 

55 The Attribute Dictionary describes a facility for encapsu- 
lating architectural mechanisms within business objects. 
Attribute Dictionary 

FIG. 58 illustrates a flowchart for a method 5800 for 
controlling access to data of a business object via an attribute 

60 dictionary. A plurality of attribute values for a business 
object are stored in an attribute dictionary in operation 5802. 
A plurality of attribute names are provided in the attribute 
dictionary for the stored attribute values in operation 5804. 
Next, in operation 5806, it is verified that a current user is 

65 authorized to either set or get one of the attribute values 
upon a request which includes the attribute name that 
corresponds to the attribute value. The attribute value in the 
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attribute dictionary is obtained or updated if the verification 
is successful and an indicator is broadcast upon the attribute 
value being updated in operations 5808 and 5810. 

In one embodiment, a hst of the attribute names may be 
outputted in response to a request. Additionally, the list may 
also include oiiy the attribute names of a portion of the 
attribute values of the business object that are present. 

In one aspect, the attribute values may be obtained for 
auditing or rollback purposes. In another aspect of the 
present invention, a dirty flag may be set upon the attribute 
value being updated. 

TiFpically, business objects include "gettef* and "setter" 
methods to access their data. How can I support value-added 
processing, such as logging events for changes, without 
impacting application code? 

Typically, business objects store attributes in instance 
variables. TTie application code for a typical setter for an 
attribute is depicted as: 



public void sctBalanccCFloat ncwBalancc) { 
myBalance ° ncwBalance; 
return; 

} 



Initially, this is straightforward. However, after all of the 
attribute setters and getters have been coded, the need may 
arise for an event to be broadcast each time an attribute is 
updated. The code for a simple setter would need to change 
to become: 



public void setBalance(FIoat newBalance) { 
myBalance » ncwBalancc; 
this.notifyCfaangedCBalance'^ ; 
return; 

) 
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changes impact application developers during coding and 
maintenance. Moreover, they also complicate business logic 
with technical details. 
Therefore, the application architecture should control 
5 access to a bxisiness object's data. This will separate out 
reusable, technical, architecture details. Business objects 
should use an Attribute Dictionary to provide an architec- 
tural hook for attribute getters and setters. Moreover, this 
framework should handle all architectural processing related 
to the update and access of data, transparently to application 
logic. 

Rather than using instance variables, the Attribute Dic- 
tionary holds all attribute values for the object. This dictio- 
nary is a collection, keyed by attribute names. Then the 
architecture can provide generic architecture methods to get 
and set attributes in the dictionary. 

Business objects could each delegate directly to the 
Attribute Dictionary within the attribute getter and setter. 
However, rather than having each business object talk 
directly to the Attribute Dictionary, simple helper methods 

^ can be created in a superclass for business objects. This 
simplifies the interface for application developers, who do 
not need to know about the Attribute Dictionary. This also 
allows for business object ^ecific logic to also be added 
prior to and after the dispatch to the Attribute Dictionary. 

^ The code for a simple setter now would look like: 



class Account extends BusinessObject { 
public void sctBalaiicc( Float newBaknce ) { 
// set my balance with the new value 
// passed in. The architecture will handle 
// any technicat details related to 
// setting the data. 

thLSJSctAttribute( "Balance'^, ncwBalance); 



Now each attribute setter must contain the call to the 
'notifychanged' architecture method. This implementation 
forces architecture mechanisms to be intrusive to application 
code. Moreover, addition or extension of architecture pro- ^ 
cessing should not impact business logic. One new line of 
code alone may not seem like a large burden on application 
developers. However, many other architecture requirements 
might later affect each setter or getter. 

As another example, before updating an attribute, a check 45 
may be required to determine if the current user has security 
rights to update attributes. Also, after successful update, a 
dirty flag may be set, or an audit log may be performed. The 
code for each setter now looks as follows: 



public void 8etBalftnce( Float newBalance ) { 
y/ keep track of my original balance^ 
// for post^change processing, then do 
// some pre-processing to check 
// that the usei has access rights 
Float oldBalance - myBalance; 
tki5.asscrtCanSctAttributc( "Balance" ); 
// finally update the balance, then 
// broadcast, set the Dirty Flag, 
// and log 

myBalance - newBalance; 
this.nGtifyChangcd( "Balance" ); 
this.makBDirty( ); 

this JogChang6d( "Balance", oldBalance ); 



65 

Thus, each added architecture framework for gets and sets 
must be manually added to all getters and setters. Such 



The architecture superclass wiU then perform the follow- 
ing: 

get the original value, perhaps for auditing or rollback 
purposes 

check if the user has security access to set the attribute 

update the attribute on the Attribute Dictionary 

if successful, broadcast and log the change 

The Attribute Dictionary would then contain the code to: 

update the value for the given attribute name 

set the dirty flag 

This illustrates that both the superclass facade and the 
Attribute Dictionary can have different processing. In 
general, one generic location for getting and setting 
attributes supports (but is not limited to): 

logging 

broadcasting 

dirty flag 

security checking 

NULL field value handling 

This logic will be either in the facade methods (for any 
code that is business object specific), or the generic methods 
on the dictionary, thereby shielding developers from this 
added complexity. 
Benefits 

Maintainability. Ardiitecture code can be added and 
changed in oae place for all objects, without change to 
the application code. 

Flexibility. The implementation of the storage mechanism 
can be changed as needed to improve performance. 
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Readability. The methods used in application code to These overloaded methods create a generic interface to 

retrieve and update fields on the object are generic. the AttributeDictionary for attribute setters. They ensure 

These methods do not have excess architecture code to type checking, such that no attributes will be set to a value 

detract from the purpose of the method. other than those for which an overloaded method exists. 

Object Model 5 public String[ ] attributeNames( ); 

HG. 60 illustrates the manner in which the AttributeDic- xhc method attributeNamcs( ) returns a collection of the 

tionaryClient 6000 is the facade which delegates to the names of only those attributes that have been populated (or 

Attnbutepictionary 6002. For example, business objects ^^j) dictionary. Hiis might be useful for other 

would mhent to behavior. AttributcDicUonaryClient 6000 frameworks, which may want to iterate over all attributes. At 

probably wouldn t be the immediate stiperclass, but it woi^d ^^^^^^ ^ ^ ^^^^^ ^^^^ 

be somewhere in the hierarchy. In this manner, staleful •* -t. , / u r i * • i *u 

business objects, like Account or Customer, can easily take f ^''^^f (^.'g- ^^^^"^^ ^^f"^ f /^^^^^^ ^^^f^ 

advantage of the Attribute Dictionary. database). So this may be a subset of the full attabute list for 

The attributcValues attribute on the Attribute Dictionary is object, 

shown as an instance of the HashMap class 6004, which Constant Class 

stores key value pairs. The HashMap Collection is used to FIG. 64 illustrates a flowchart for a method 6400 for 

provide access to attribute values based on the attribute managing constants in a computer program. In operation 

name. This is required for a direct lookup of values associ- 6402, a plurality of constant names are provided with each 

ated with attribute names. Such lookup can iise string constant name having a corresponding constant value. The 

representation of the attribute names. constant names are grouped into constant classes based on 

Object Interaction Diagrams 20 an entity which the constant values represent in operation 

There are four interactions for this framework: Simple 6404. Access is allowed to the constant values in operation 
Attribute Getter, Simple Attribute Setter, Failed Attribute 6406 by receiving a call including the corresponding con- 
Getter, and Retrieval of Attribute Names. FIG. 61 illustrates stant name and corresponding constant class, 
the internal implementation of the dictionary. in one aspect, the constant values may be changed upon 

HG. 61 depicts the use of the containsKey() method 6100 25 being accessed. In another aspect, the constant value may 

on the HashMap to ensure that the value will exist before the also include an enumeration. Also, in one embodiment, 

get( ) method is used. This proactive search for the value accessor logic modules may be assigned to a plurality of the 

ensures that the nullPointerException is not thrown from the named constants with the accessor logic modules being 

AttributeDictionary. The performance of such methods will executed upon the accessing of the corresponding constant 

be checked during testing. If such processing is not 30 value via the accessor logic module. Also, the accessor logic 

perform ant, the code can be altered and the call to modules may be edited per the desires of a user. 

containsKey( ) removed. In that case, the HashMap wiU AdditionaUy, the constant values may be accessed without 

need to wrap a fry-catdi block around the get( ) method. the accessor logic modules. 

FIG. 62 illustrates a method 6200 that dictates that any Uterals are hard-coded constants referenced in multiple 

nullPointerException that is thrown would be caught and 35 places. How can source code refer to Uterals in a maintain- 

rethrown as the more user-friendly exception in the attribute able fashion? 

dictionary pattern envronment. HG. 63 illustrates the Get jhe concept and value of named constants have been 

the Attribute Names method 6300 in the attribute dictionary realized for quite some time. The idea can date back to 

pattern envronment. Assembler language naming memory locations where data 

Public Interface 40 was stored. The purpose is to give the ability to refer to fixed 

The following are methods on the AttributeDictionary valuesby the name of what they represent rather than by the 

The AttributeDictionaryClient exposes similar public meth- quantity they are set to. 

Named constants allow a programmer to **parameterize" 

public Object getAttribute(String attributeName) raises a system. This allows a programmer to change a constant's 

AttributeNotFoimdExcepdon; 45 value in a single place rather than every place the constant 

The return value of getAttribute( ) is typically a wrapped is used. In addition to the maintenance gain, readabihty is 

primitive, or Java type, for most attributes. This includes, for also increased. 

example, an account balance (Float) or account number Many languages offer mechanisms to implement named 

(String). The return value of these wrapped primitives must constants. These include PoolDictionaries (Smalltalk), 

be cast, as illustrated in the following example: 50 enums (C and C++) and public static final declarations 

(Java). Difficulties arise during implementation of these 
mechanisms with respect to type constraints, visibility, and 

class Account extends Buaiaess Object { ^^^^ cheddng. 1., 

public Float getBaiam:e( ) { ^sing these tradiUonal approaches, results m global 

// get my balance using the superclass fecade 55 namespace for these literals. This can result in name colli- 

// cast the return value before ictuining it sions. For example, the name HIGH to define a 



return (Fioat)(tbis.getAttribute( "Balance" )); magnitude could translate into different values for different 
J uses. A HIGH temperature could be 95 while a HIGH 
altitude could be 39000. 



^ , , ^ . . 60 In addition, constants often belong to logical groupings. 

Other methods on the AttributeDictionary mclude: p^^ instance, STOCK, BOND, and OPTION arc all types of 

public void setAttribute(String attributeName, Boat financial instruments. These belong in a some sort of col- 
attribute Value); lection. 

public void setattribute(String attributeName, String A consistent, quality method to represent constants in an 

attribute Value); 65 object-based system is required. 

public void setAttribute(String attributeName, Busines- Therefore, represent named constants in a separate class, 

sObjcct attribute Vahie); grouping categories of constant values together within one 
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name space. Constants tend to naturally fall into logical 

groupings. Each grouping should be represented by its own -continued 
class. For instance, all of the constants used by a Phone- 
Number object to capture the various types of PhoneNumber 
(i.e. home, business, fax, cell, pager, etc) can be accessed 
through a PhoneiypeConstants class. 

If constants are obtained by other means than explicit 
language constructs like "public final int HOME_ 
ADDRESS" than public accessors are used to insulate a 
client from changes in how the constant is obtained. In this 
case the values of each of the constants shotild be defined 
privately inside the Constant Class. Public accessors are 
then provided for clients to obtain the constant values. This 
allows for "changing constants". Business-related values 
that may seem constant at design and construction time very 
often are not. Some of these "constants" may eventually 
require some logic to determine their value. If clients obtain 
constants through accessor methods, no changes (except 
within the accessor) will have to be made if the logic is 
added. This is a particularly safe practice when program- 20 y 
ming rules dictate all constants to be stored and retrieved } 
from database tables. . 

In the case where constants are defined within the class ^ . , . , . 

itself most 00 languages, excepting Smalltalk, allow for This type partition is used by PhoneNumber. See mam( ) 
some type of const definition. In this case by using a const 25 for uncommenting a line that demonstrates the type safety 
construct (i.e. static final int PhoneNumberType FAX=new - - - ^ ^.^..^ 



10 



15 



pnvate final tnt phoncKumberlVpcOid; 

private final Striag typeld; 

private Phon6Numbeiiype(iiit i. String id) { 

phoneNumbciTypeOrd - i; 

typeld • id; 

typ cs .addEleincnt(this) ; 

> . 

public final static Enumeratbn elements ( ) { // allows foi 
eaumeiation 

return type8.elements( ); 

} 

public static void main(String args[]) { 

Enumeratioa elements - PhoneKmnbeiiype.elements( ); 

PhoncNambciTVpc pt; 

while (element5.hasMoreElements( )) { 

pt - (PhoneMumbeiiype)clcmcnta.nextElcmcat( ); 

System.outprintln(pt.toString( )); 

} 

} 

public String toString( ) { 
return typeld; 



PhoneNumberIVpe( )) it is not necessary to have public 
accessors and private definitions. Declare the class type, 
create static final instances of the type and do not provide a 
public constructor. This ensures the type safety and provides 
easy to access members in the Eiffel style. 

Moreover, public accessors in either strategy provide for 
type-safe enumerations. Enumeration is a special type of 
constant that deserves attention. A TypeConstant class can 
provide enumeration by implementing some key methods 
that provide for supporting iteration over the elements of the 
enums. In Java, for example, this entails implementing the 
Enumeration interface. 
Benefits 

Maintainability. Groups all valid values together and 
ensures they can not be created or passed as parameters 
by any other method. 
Type Safety. Enumeration values can be type-checked by 

a compiler in method parameters and return values. 
A common appUcation pattern where this use of constants 
was applied was in the modehng of instances vs instance 
types where the types added no additional behavior. In two 
different customer care applications this came through as the 
objects like PhoneNumber, PhoneNumberType, RatePlan & 
RatePlaniype, etc. This example has not yet been updated to 
JavaBeans. 



protection through the use of static final and private con- 
structors. 



30 
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package Party; 

import javaio JetStream; 

import javaicStringWritcr; 

public class PlioneNumber 

{ 

private PhoneNumbeiType phoneNumbcriypc; 

private String aieaCode; 

private String prefix; 

private string sufGx; 

public PhDneNiimber( ) { 

areaCode - null; 

preiix » null; 

suffix - null; 

} 

public PhoneNumber(String aPhoneNumbei) 



{ 



45 



} 



paFsePIioneNumbei(aFfaoneNumber); 
setPhoneNumbeiTypeCPhoneNumbeiTVpc.HOME); 



public PboaeNumber(StrLng anAreaCode, String aPrefix, String aSuffix) 
{ 



50 } 



areaCode - anAreaCode; 
preAx - aPrefix; 
suffix « aSuffix; 



package Party; 

import Java. util.*; 

public dass PhoneNumberType { 

static final Vector types » new Vector( ); 

static final PhoaeNumberTVpe FAX - new PhoneNumber'IVpe(0, 
"Flax"*); 

static final PhoneNumbeiType CELL - new PhDneNumbeTType(l, 
"Cell Phone"); 

static final PhoneNumberType HOME « new PhDneNumbeiType(2, 
"Home"); 

static final PhoneNumbeiType WORK - new PhoQeNumbciTypc(3, 
"Work"); 

static final PhoneNumberType PAGER - new PboDeNumbcrType(4, 
"PageO; 



55 



public String aieaCode( ) 

{ 

return areaCode; 

} 

public void aFeaCode(String anAreaCode) 
{ 



areaCode « anAreaCode; 



65 



} 

public boolean equals(Stiing aPhoaeNumbei) 
{ 

PhoneNumber tempPhoneNumber - new 
PhoneNuinber(aPhoneNuinbei); 

return equals(temp PhoneNumber); 

} 

public boolean equals (PhoneNumber aPhoneNumber) 

{ 

if (aicaCodc( ) mill && aPhoiieNumbei.arcaCodc( ) !■ 
aPho[ieNumber.areaCode( ) — null && areaCode( ) l« null) 
return fiilse; 
if (aieaCode( ) I- null) 



null II 
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{ 

if (attaCode( ).equalB(aPhoneNumber.areaCode( )) && 
prefix( ). equals (aPhoneNuinber.prefix( )) && 

sufiSx( ).cquals(aPhoneNuinber.suflBx( ))) 
letum true; 

else 

return false; 

} 

if (prcfii( ).equals(aPhoneNuinbcr.prefix( )) && 
suf5x( ).equals(aPhoneNuinbei.8uffix( ))) 
return tiue; 

else 

return felse; 

} 

public static void inaiii(String argv[]) 
{ 

PhoneNumber aPhoneNumber; 

Sy8iein.ouLpriiitla(Testiiig constiuction & comparisonl"); 

if (aigv.length •«» 0) 

{ 

System.out.prittUiv(**Test with tto area code - no masks"); 

aPhotteNumbci - new PhoneNumber(" 5579203"); 
aPhoneNuinber.8etPhoneNuinbeiiype(PboneNuinber'rype.FAX); 

Syste[n.out.priiitln(aPliotteNumber.toString( )); 

System.out.printIn(Tcst with area code - no masks"); 

aPhoneNumber - new PhoneNumbeT("206SS7203y^; 
aPhoiieNumbetsetPhDneNumberiype(PhoneNumberTVpe.WORK); 

System.outpniitIn(aPhoneNumber.toString( )); 

System.out.pnntln(*Test with normal ma^"}; 

aPhoneNumber = new PhoneNmnbtr('*(206) 557-3920"); 
aPhoneNumbei;setPhDneNumbeiType(PhoaeNumbeilVpe.PAGER); 

System.out.prtntln(aPhoueNuinbei.toString( )); 

System.outpiintln(*Test equality S578215 557-8215"); 

PhoneNumber tempi - new PhoneNumberC*5578215"); 

temp 1 .setPhoneNumbeiTVpe(PhoneNumb eiTVpe.CELL); 

PhoneNumber temp2 - new PhoneNumber("557-8215'^; 

tcinp2.setPhoneNumbcrTVpe(PhoneNumbeiTypc.CELL); 

// tempXsetFhoneNumbeiType(new PhoneNumbeiType(6, 
"TOV*)); // enum type safety w/private ctor 

SysteaLout.println(teinpl ) ; 

System.out.println(temp2) ; 

System.out.pnntla("templ «■ tcmp2: ** + 
ten^l .equals(temp2)); 

return; 
}elsc { 

aPhoneNumber = new PhoneNumbcr(argy[0]); 
System.out.pTintln(aPhoneNumbcr.toStrLng( )); 

} 

}. 

private void pars cPhoncNumbcr (String aPhoneNumber) 

{ 

StringBuffer aStr - new StringBu£fer(aPhoneNumber.length( )); 

int i o 0; 

do 

if (Character.i5Digit(aPhoncNumbcr.charAt(i))) 
aStr.app«id(aPhcineNumbcr char At(i)) ; 
while (i++<aPhoneNumberJength( ) - 1); 
String tempString - new String(aStr); 
if (aStLlength( ) ~ 7) 
{ 

prefbE(tempString.sufastring(0^ 3)); 
su£Gx(tempStiing.substring(3, 7)); 
ictuni; 

} 

areaCode(tempString.substring(0, 3)); 
preflx(tcmpString.substring(3, 6)); 
su£Ex(tempString.sub6tring(6, 10)); 

public String prefix( ) 

return prefix; 

} 

public void pTefix(String aPreftx:) 
{ 

prefix - aPrefix; 

} 

* Tbla method was created by a SmartGuidc. 

* @param sw StringWriter 



*/ 

public void printOn (StringWriter sw) ( 
5 5w.write(((areaCode !- null |] ajeaCode — "^O ? ("(" + 

areaCode( ) + 

11 : "")); 

5w.writc(this.prefix( )); 
sw.write("-'*); 
sw.write(thi5.suffix( )); 
10 return; 
} 

public void sctPhoneNiraibciiypc(Phon6NumbeiType pnt) { 
phoneNumberiype - pnt; 

public String suffix( ) 
15 { 

return suffix; 

} 

public void suffix(String aSuffix) 
{ 

sufiGx a aSufiSx; 

10 ^ 

public String toString( ) 
{ 

return new String(phoneNiimbcrTypc.toString( ) + ":"+ ((arcaCode 
!= null [| arcaCode — ? ("(- + 
areaCode( ) + H : «") + pTefix( ) + +BuflSx( )); 

^ } 

Alternatives 

Smalltalk allows for grouping logical constants in Pool- 
Dictionaries as in Textdbnstants. This is simply a global 
dictionary with key value pairs that simplifies and improves 
readability by using well understood names like "Space" and 
"Tab". However, they are global variables and they are not 
automatically recreated when you file in code that depends 
on them. 

55 When constants arc implemented in a class within Small- 
talk accessors must be used. There is no real language notion 
of final or const in SmalUalk that woxdd allow for accessing 
member variables. 

Communications Services Patterns (1008) 

40 An original tenet of component-based design has been 
simplified distribution of functionality. According to the 
original argument, up-fironl definition of component bound- 
aries and their interfaces would simplify the configuration of 
functionality on the network Even though component-based 

45 design has simplified distribution, it has not guaranteed 
success. Networks introduce performance issues and failure 
conditions that didn't exist in non-distributed solutions. If a 
solution is to be successful, these issues can't be ignored. 
Each pattern in this section addresses a difficulty associ- 

50 ated with distributed computing. Every pattern reflects a 
problem and a solution to issues encountered by other 
development teams. 

Legacy systems running on mainframes, Unix boxes, etc. 
are an important part of today's client projects. The majority 

55 of today's clients have existing computer systems that 
cannot be easily rewritten or ignored. Integration of these 
older systems with the newly developed applications is often 
imperative to the success of the project. Any newly devel- 
oped components must leverage the existing functionality on 

60 these Legacy systems. The Legacy Wrapper pattern 
addresses this problem. It describes a common pattern for 
tackling the integration issues associated with reusing func- 
tionality from existing systems. 

Server-side components implement services for use by the 

65 Clients in an application. These components should clearly 
specify the interfaces and services they provide, but how 
should they make them available? A well-known central 
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service, e.g., a Name Service or Trader Service can be used object-based systems. In a third situation, both of the sys- 

to make the interfaces available to all Clients, but is that tcms may be non-object-based systems, 

always warranted or prudent? Should every Qient have Stream-based communication is a very effective pattern 

access to every service? The Locally Addressable Interface for relaying data, data structures, and meta-data. Meta-data 

(LAI) and Globally Addressable Interface (GAI) patterns 5 is information about the data like data structure, data types, 

describe two approaches to this problem. ^"^S * shared, generic format. How can the message 

The performance characteristics of remote components ^® shucd between systems so as to create the most 

are very difEerent from "in process^* components. The cost of straightforward and best performing stream-based mecha- 

requesting and transmitting data between remote compo- ^^^1 - ^ . • * 

4, ' Lu*u 'J J" j**t.-« Uiten, it IS aetermmed that a stream-based communica- 

nents is much higher and should be considered in a distrib- lo,. . , ,-.t. wi^ixii^xva 

X J 1 A ii J- * * J 1 a. II r uon mechanism snould be used to transport information 

uted solution. As a result distnbuted solutions often call for ^^^^^ ^ Stream-based communication is a pattern 

communication patteri^ that miprove upon the performance ^^^^^ information is transported from one system to iiother 

aspects mos important to the system. The Structure Based ^ 3- ^ ^^^^ ^^^^ ^ ^^^^ 

Commumcation pattern addresses the "chattmess" associ- structure and meta-data information, 

ated with distributed appHcations, It helps reduce network 15 pio. 66 illustrates two systems 6600 communicating via 

load and mcreases system response time. The Paging Com- a stream-based communication 6602 and using a common 

munication pattern addresses the common need to retrieve generic format to relay the meta-data information, 

and display large lists of data. It shows how incremental However, when implementing St re am -based 

fetching can be used to provide much better perceived Communication, a number of factors influence the method 

responsiveness in GUI based applications. 20 for enabling each system with a "shared format." The 

The cost of locating a remote service and establishing a "shared format" provides the meta-data information needed 

connection to that service can also be a costly endeavor. The to interpret the raw data in a stream. This shared format is 

Refreshable Proxy Pool pattern describes a robust and lite a secret decoder ring for systems sending and receiving 

efl&cient way to minimize this "lookup" activity. messages. It allows the systems to convert structured data 

Most recent component-based systems use middleware 25 (objects, strings, etc.) into raw data and raw data back into 

such as CORBA, DCOM or Java RMI to specify the structured data. This is needed to transmit the structured data 

interfaces provided by components and the associated data across the network, 

types. However, such middleware is not always available, or projects, the following factors influence the 

directly appHcable. In such situations the Stream Based ^^^^ communicating using a stream. 

Communication pattern, or one of its descendants, the Fixed 30 High performance — System performance is always a 

Format Stream and Self describing Stream patterns might be factor, but sometimes it is one of the most important 

applicable. These patterns describe different techniques for factors in a system. 

efficiently streaming data between processes. While they all Short development time — ^The system must be opera- 
share a common solution to a common problem, the solu- tional in the shortest possible timeframe, 
tions present different tradeoffs between implementation 35 Stable information characteristics — ^In some solutions, the 
simphcity, performance and flexibihty. data and the structure of the data are stable and unlikely 

A Null value represents the "empty set" and is an impor- to change, 

tant value in distributed component solutions. In cases like this, how can one optimize the benefits of 

Some languages, such as Java, support Null as a specific stream-based communication and implement only the most 

value, whereas other languages do not (e.g., C++ which uses 40 basic capabilities that one requires? 

zero and context to determine NuU). This language mis- Therefore, use the Fixed Format Stream pattern to create 

match can cause problems in distributed systems that use a stream-based message that uses fixed format contracts to 

more than one language. The Null Structure pattern share the formatting uaformation and meta-data between 

describes this problem and proposes a solution. systems. 

Fixed Format Stream 45 Fixed format contracts are maps that contain the meta- 

FIG. 65 illustrates a flowchart for a method 6500 for data information such as the data structure, data separators, 

providing a fixed format stream-based communication sys- data types, attribute names, etc. They describe how to 

tem. In operation 6502, a sending fixed format contract on translate Fixed Format messages onto a stream and off of a 

interface code is defined for a sending system. A receiving stream. 

fixed format contract on interface code is also defined for a 50 FIG. 67 illustrates an example of a Fixed Format message 

receiving system. A message to be sent from the sending 6700 associated with the fixed format stream patterns. The 

system to the receiving system is translated in operation locationandsizeof each attribute in the message is fixed and 

6504 based on the sending fixed format contract. The knownatdesigntime. In the example below, it is known that 

message is then seat from the sending system and subse- the command will be in bytes 1-9, the first name will be in 

quently received by the receiving system in operations 6506 55 bytes 10-29, the last name in bytes 29^9, etc. This infor- 

and 6508. Hie message received by the receiving system is mation (meta-data) is used by the Fixed Format contracts to 

then translated based on the receiving fixed format contract convert Fixed Format messages from data structures to raw 

in operation 6510. data and back again. 

In one embodiment of the present invention, information FIG. 68 depicts the complete Fixed Format Stream pattern 

in the translated message received by the receiving system 60 associated with the fixed format stream patterns. A data 

may also be stored in a relational database. In one aspect, the structure on System A 6800 is translated to a Fixed Format 

fixed format contracts may be included in meta-data of the message (raw data) using a Fixed Format contract. The 

message. Also, in another aspect, the message may include message is put in the stream 6802 and sent to System B 

an indication of a version thereof. 6804. System B 6804 receives the Fixed Format Message 

In one situation, one of the systems is an object-based 65 (raw data) and uses its Fixed Format contract to recreate the 

system and one of the systems may be a non-object-based data structure. The same process works in reverse when 

system. In another situration, both of the systems are may be System B 6804 responds to the message request. 
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Benefits 

Performance. Because there is no time spent on look-ups 

or dynamic translation of the message, performance is /•• stream my attribute values ou aStream •*/ 

better than with other variations of Stream-Based Com- jpMic void streamOn (Ou^utstieam aStream) 

mumcation. aStrcam.write(this.getNainc( ).asString( ).padWithSpaces(10)); 

Small Message Size. Each Fixed Format message con- aSti«am.write(this.getScx( ).asstring( ).padWithSpaces(7)); 

tains only daU to be sent to the other system. These aStxam.writc(thiB.gptAgc().a5String().padWthSpaccs(3)); 

messages contain no meta-data and are smaller than 



those in Self-Describing Streams. lo 

Simplicity. Translating and parsing information onto and ^' stream is then put into a message communication 

off of the stream is straightforward and easier than with mechanism hke MQScries or MessageQ and sent to the 

the other variations of Stream-Based Communication. non-object system. 

The behaviors for the Fixed Format Streaming are ^- ^« non-object system, interface code reads 

contained in the fixed format contracts on the interfaces through the stream, parses the values off of the stream, 

of the sending and receiving systems and thus easy to converts them to the appropriate types if required, and 

find. P^^ them in a copybook with the appropriate structure. 

r^u- * r? * ji TT.- ** * ■ u*r j * ^ this cxamplc, the fixed format contract is embodied 

Object Friendly. This pattern is very straightforward to • *u * * j * * *l ti7o oTTAnT-T>. 

implementmobjectbasedsystems'Tl,eobjectscontain ^ vc,^^ TAT^c^^L^" v f ^S-SHARED- 

the fixed format contracts aad manage the translation l^I^^^^l^^TrLT^T ^ ""^^ 

J * 41. . Refer to the pseudo-COBOL example below, 

and parsing onto the stream. These objects can access ^ ^ 

their own private behaviors which makes the interface 

much simpler. 

Implementing this pattem is very straightforward. Define 25 ■ ■ 

corresponding fixed format contracts on the interface code data division. 

of both the sending and receiving systems. FIG. 69 illus- ^ FILE-STREAM-IN 

*,«f^-. fi^ ^ * ™ 7 * * ico^ ^ • • * J * RECX)RD CONTAINS 20 CHARACTERS 

trates fixed format contracts 6900 contammg meta-data 

information for translating structured data onto and off of a working-storage SEcnoN. 

stream. ** • this copybook contains the common format of 

In non-object systems, define a fixed format contract on 

tu^ i^to^o^^ tu^ .^^Ai^^ ***customerinthedaiastructureand datatypes 

the parsmg mterface module of the sendmg system. The ws-common-format-cu^mer 

interfacing module on the sending system can use the 03 ws-common-format-name picx(10). 

contract as a map for how to translate and write the data onto 03 ws-common-format-sex pic x(7). 

the stream. Define a corresponding fixed format contract on « ws-common-FORMAT-age pic 999. 

the interface modules of the receiving system. The interface ;7^^co™ 

module on the receiving system can use the contract to read 03 ws-name pic x(io). 

and translate the data off of the stream. 03 ws-age pic 999. 

In obj ect-based systems, make each object responsible for ws-SEX Pic X(10), 

its own fixed format contract. Using this contract, each ^ procedure division 
object is able to retrieve and parse its attribute values onto 

a stream as strings (streamOn) and each object class should OPEN THE file stfream and put the contents in the 

be able to parse attributes off of a stream and put them into ws-common-FORMAT-CUSTOMER copybook. 

OPEN FTIJ' ^niRAM IN 

a new instance of an object (streamOff). Also, it is good file'stream-in into ws-common-format- 

practice to include the version of the format within the customer 

stream so that concurrent format versions can be accommo- af-end close hle-stream-in 

dated in the design. end-read. 

Below is a pseudo-code example of an object-based ;;;^ove raE values into niOM THE common format 

system communicating with a non-object system using *** the ws-cusroMER variables. 

stream-based communication and a fixed format contract. MOVE ws-COMMON-FORMAT-SEX TO ws-SEX. 

FIG. 70 illustrates a Customer object 7000 in an object- ws-common-format-age to ws-agel 

based system 7002 streaming itself into a stream 7004, the ws-COMMON-FORMAT-NAME TO WS.NAME 

stream being sent to a non-object system 7006, this stream CALL A SQL MODULE TO SAVE THIS INFORMAnON IN 

being read and the data inserted into a relational database THE 

7008 *** RELATIONAL DADVBASE 

'r^ ^ ^ 55 CALL "SAVE-CUSTOMER-IN-DATABASE" using WS- 

1. The CustomerObject with attributes name, sex, and age customer. 
has a method "streamOn: aStream." It is invoked with 

an empty stream as the argument *aStream^ The Cus- groP-RUN. 

tomerObject "streamOn:" method goes through each of ^— — — ^— " 
the object's attributes and parses each values as a string ^ Conversely, a stream could be created by a non-object 

onto the stream. system (or another object-based system for that matter) and 

The fixed format contract here is embodied in the order sent to one's object-based system. In this case, Customer- 

that this method parses the attributes onto the stream. A Object could use a "streamOff: aStream" method and instan- 

pseudo-code example in Java is the following: Note- tiate a new instance of an aCustomerObject and populate it 
Assume that "asString( )" converts the receiver to a 65 with the appropriate attribute values, 

string and that "padWithSpaoes( )"pads the string with Eagle Architecture Framework: Uses Stream Based Com- 

spaoes and makes the string the length specified. munication in a number of ways. First of all, it uses it 
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to embed tracing information in CORBA distributed In a typical two or three-tiered client-server application, 

requests. Second of all, it is used to replicate state the services are maintained away from the users (Client) on 

between fault-tolerant services. separate Server machines. Whenever a user needs to use a 

MCI: Invoice Development Workbench. This workbench service, the user must send a request across the network to 

helps MCI create error-free invoice definitions for the 5 the Server machine. 

various Local Bells. Stream-based communication was Before a client can utilize a service, it must find the 

used as part of an efficient, lightweight persistence service. Ifthe client is unable to find the service, it can't ever 

mechanism. use it. FIG. 72 depicts a client 7200 that is unable to find the 

Java Serialization: This is a Java defined fixed format for services provided by a server 7202 via a network 7204. 

streaming objects. 10 client could look for services in a naming service. 

Object Request Brokers (ORBs) that use CORBA, However, if the services don't exist in the lookup or naming 

DCOM, or Java Remote Method Invocation (RMI) — service, the client still can't find and use the service. 

ORBs that use one of these standards implement this Therefore, use a Globally Addressable Interface to expose 

pattern. They define an Interface Definition Language services to all available clients. 

0DL) that is the format or contract of the stream and a Globally Addressable Interface builds upon the Inter- 
use stream-based communication as the commtinica- face pattern and the Naming pattern. When implementing a 
tion rnedium. Globally Addressable Interface, a Server's operations are 

Collaborations bundled into logical groups using the Interface pattern. 

Stream-based CommunicaUon. This is the parent pattern 73 iu^^rates the grouping of services 7302 using 

to Fixed Format Stream. In this pattern, information is interfaces 7304 

teansmitted ^ing a simple stream and a shared generic ^ example/all the operations for accessing and viewing 

format. The Fixed Format Stream IS a more specific imp le- ^ * ^ ^ . r^. * 

mentation of Stream-Based Communication. ^^f 1°°^^' S^ll Customer, Get Customer 

Structure Based Communication-Hiis pattern uses a ^^;) "^^l^^ ^ "^^ interface An the 

Fixed Format Stream to transmit data structure between operations for changmg customer mformation (Change 

systems. It is often used to obtain data from a Server for 25 Customer, Address, Change phone number, etc.) might be 

display in a Client UI. bundled into another interface. Keep in mind, this is an 

Bridge (from the Gamma book Design Patterns) describes example "bundlirig" of operations and not the definitive 

a way to de-couple an abstraction from its implementation method for bundling operations. 

so that the two can vary independently. The Bridge pattern Oiice all the operations have been grouped into an 

is often used to define collaborations between a business 30 interface, the interface is given a name appropriate to the 

object and a format object while decoupling the business operations it bundles. Then the interfaces are announced 

object from its specific stream format. the Naming pattern. The Naming pattern enables 

Abstract Factory (from the Gamma book Design Patterns) registration of interfaces in a globally available naming 
is a pattern for creating families of related classes. This service. FIG. 74 illustrates a customer server 7400 is pub- 
could be used with the Bridge pattern to retrieve the format 35 My announcing its interfaces 7402. 
dynamically based on non-static information. Until that time, a client can't find the operations and can't 
Altematives ^ them. Thus, the Server must use the Lookup or Naming 

Self-Describing Stream. This pattern is a specific imple- pattern to register its interfaces (not methods). Once the 

mentation of Stream-Based communication where the mes- interfaces have been registered with such a service, any 

saging format is parameterised and stored on the stream. A 40 client can go to the Naming Service, locate an interface, and 

message language is used to read and write the format of the access an operation in that interface, 

message from the stream. Benefits 

Downloadable Format Stream — This pattern is a specific Public Addressability— Every Globally Addressable 

implementation of Stream-Based communication where the Interface is publicly available for use by any client As 

messaging format is stored at a central location and is 45 a result, any Client can find these interfaces and access 

downloaded by the communicating parties when needed. these operations. 

Globally Addressable Interface Stateless Load Balancing. Globally Addressable Inler- 

FIG. 71 illustrates a flowchart for a method 7100 for faces are generally implemented for stateless Servers, 

delivering service via a globally addressable interface. A When Stateless Servers are used, it is a lot easier to 

plurality of interfaces are provided in operation 7102 and so balance the incoming load. Since state or context is 

access is allowed to a plurality of different sets of services always passed into the Server, any call can be directed 

from each of the interfaces in operation 7104. Each interface to any Server that supports a particular operation. If one 

has a unique set of services associated therewith. Each of the is busy, the Client can be forwarded on to the next one. 

interfaces is named in operation 7106 with a name indicative The following is a message trace diagram depicting the 

of the unique set of services associated therewith. The names 55 interactions associated with a Globally Addressable Inter- 

of the interfaces are then broadcast to a plurality of systems face. 

requiring service in operation 7108. The Message Trace diagrams depict a common Client- 

The access may be allowed via structured-based commu- Server scenario. A client requests customer data from a 

nication. As another option, the names may be broadcasted Server. The Server finds the data in a database and forwards 

using a naming service. Also, the naming service may so it back to the client. The Client can then display the data in 

provide the systems requiring service with a location of the a User Interface for a user. 

interface on a network. In addition, the systems requiring The scenario was broken into two message trace dia- 

service may be capable of looking-up the interfaces using grams. The first message trace sets the stage for the second, 

the naming service. In the first message trace, the Server registers two Globally 

In a client-server environment, a client makes requests of 65 Addressable Interfaces with a Naming Service. The Client 

services on a Server. In such an environment, how might a then "looks-up" an interface and establishes a connection to 

Server expose its services for use by one or more clients? that interface. 
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Assumptions 

CORBA ORB connects Client and Server 
CORBA Naming Service used to lookup GAIs 
FIG. 75 illustrates a method 7500 including the register- 
ing and then locating of a globally addressable interface. 
Collaborations 

la, "Bind** the interface name (Update Interface) with it's 
Remote Object Reference (network location) in a Naming 
Service, nis will allow clients to "lookup" the interface. 
Once the Interface is registered in the Naming Service, it 
has become globally addressable. Any client can find the 
interface and access a operation. 

lb. "Bind" the second interface in the same manner as the 
first. 

2. The client instantiates a Proxy (Browsing Interface Proxy) 
to the Browsing Interface on the Customer Server. 

3. The Proxy "looks up" the network location of the Brows- 
ing Interface. It makes a request of the Naming Service. 
It requests the network location of the Browsing Interface. 

4. The Naming Service returns the Remote Object Reference 
(network location) for the Browsing Interface. The Proxy 
now has all the information it needs to access an operation 
on the Browsing Interface. 

The second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and returns it to the Client. The Client 
can then display it in the UI. 

FIG. 76 illustrates the present invention using a method 
7600 wherein a globally addressable interface is used to 
obtain data from a server. The steps associated with the 
method 7600 of FIG. 76 will now be set forth. 
Collaborations 

5. The Client asks the Browsing Interface Proxy for the data 
associated with customer 1234. 

6. The Browsing Interface Proxy forwards the request across 
the network to the Browsing Interface. 

7. Same as 6. 

8. The request is forwarded to the Customer Server. The 
Customer Server requests the customer data from the 
Database. 

9. The Database returns the customer data for Customer 
1234. 

10. The Customer Server creates a structure and populates it 
with the customer data. 

11. The Customer Structure is forwarded through the Brows- 
ing Interface, across the network and back to the Brows- 
ing Interface Proxy. 

12. The Browsing Interface Proxy forwards the Customer 
Structure to the Client. The Client can now display the 
data in a UI for a user. 

IDL Interfaces and Structures 

The following IDL defines the two Interfaces and Sttuc- 
tures used in the message trace diagram s above. 



module CustomeiServer 
{ 

// CX)RBA IDL for the Update Interface 
interface CustomerUpdatelntetfiaoe 
{ 

void changeCustomer( long anid, 
conunonDefs::CustoinerStructuie aCustomer); 

void changeAddrcss(Long anId, 
commonDefs : : AddressS tructuie aNewAddress); 

string changePhoneKumber(lang anId, string 
aNewPhoncNumbei) ; 
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•continued 



10 }; 



}; 

// CORBA IDL for the Biowsing Interface 
interface CustomerBrowsinglaterfBoe 
{ 

oQmnionDefiB::CustoinerStnJcture gptCustomerQong anId); 
ooniinonDe&::Addre8sStructuic gctAddrcss(Long anld); 
string getFhoneNumber(long anld); 

}; 



// This module defines the structures passed through the two // customer 
interfaces, 
module commonDe& 

{ 

stiuct AddiessStiucture 
15 { 

String street; 
string city; 
string state; 
string zjp', 

string phoneNumber; 

}; 
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}; 



struct CtistomerStructurc 
{ 

string id; 
string status; 
string firstName; 
string lastName; 

}; 



30 



Sample Code 

The following is some Sample Java code for the Skeleton 
portion. 
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//Pass all requests on to the Component for processing 
35 public CustomeiStructure gctCustomer( 
String aCustomerld) 

{ 

CustomerComponent aCUstomerComp = this.getComponeni( ); 
retum(aCustomerCoit^.getCustomer(aCustomer[d)); 

//Pass all requests on to Uie Component for processing 
public String getPhone(Stnng aCustomerfd) 
{ 



} 



The next snippet of code is for the Customer Component 
(Server). The interface delegates the processing to the com- 
ponent. 
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// Get the Customer*s data and return it 

public CustomeiStructure gctCustomer(String aCustomerld) 

{ 

// Go to the database and get the 

// customer with the appropriate ID 

Customer aCustomer - ... 

// Create a structure and populate it with the 

// customer data retrieved Stom the DB. ' 

Customer Structure aCUstomerStructure - new 
Customers tmcture( ); 

aCustomerStructure.id - aCustomer.getId( ); 

aCustomerStructure. status > aCustomer.getStatus( ); 

aCustamerStructure.fiistName > 
aCustomer.getFirstName( ); 

aCustomeiStructure. lastName - 
aCustomer.getLastName( ); 

return (aCustomerStmcture); 
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-continued 

public String gctPhoiic(StrLng aCustomciId) 
{ 



} 

public Address Structure getAddiC8s(Striiig aCustomerld) 
{ 

} 



Additional Considerations 

Ibe GAI class is actually represented by two different 
classes (and the Component itself). Each GAI is made up of 
a Proxy and a Skeleton. The Proxy represents the interface 
on a Client while the Skeleton represents the interface on a 
Server. 

Collaborations 

Proxy — ^The proxy pattern is generally used to commu- 
nicate from a aicnt to a Globally Addressable Interface on 
a Server. 

Structure Based Communication — Often times, a client 
needs to display data in a UI for a user (e.g. Customer 
Information, Order Information, etc.). When communicating 
through a Globally Addressable Interface, this data is trans- 
mitted from the Server to the Client using Structure Based 
Communication. 

Load Balancing — When a number of servers implement 
the same Globally Addressable Interface, the Load Balanc- 
ing pattern is used to balance Oient requests between these 
Servers. 

Proxy Pool — ^The Proxy Pool pattern helps balance the 
cost of instantiating Remote Proxies and retaining Proxy 
"freshness." The Proxy Pool pattern can be used to create a 
pool of Proxies to Globally Addressable Interfaces. 

Locally Addressable Interface — ^Locally Addressable 
Interfaces are private interfaces that aren't easily located. 
Generally, a well-known interface (like a Globally Addres- 
sable Interface) is used to find a LAI. A Client easily find and 
access a service on a Globally Addressable Interfaces and 
request a reference to a Locally Addressable Interface in 
return. 

Interface — The Interface pattern defines methods or func- 
tions or services rather than implementation. The Interface 
pattern is expanded upon by the Globally Addressable 
Interface pattern. 

Naming — ^The Naming pattern describes a pattern for 
registering and finding services or objects etc. where they 
can be easily found in an application. The Naming pattern is 
often used to register Globally Addressable Interfaces so 
they are publicly available. 
Alternatives 

Locally Addressable Interface — The Locally Addressable 
Interface pattern is both a collaborating and alternative 
pattern. It can be used to retrieve information from Servers 
instead of Globally Addressable Interface. 
Legacy Wrapper 

FIG. 77 illustrates a flowchart for a method 7700 for 
affording access to a legacy system. A plurality of compo- 
nents coupled to a client via a component integration archi- 
tecture are provided for servicing the client in operation 
7702. A legacy system is intercormected to the client via the 
integration architecture using a legacy wrapper in operation 
7704. In operation 7706, the legacy system and the client are 
interfaced via the legacy wrapper by communicating with 
the client by way of a first protocol and by communicating 
with the legacy system by way of a second protocol. 
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As an option, the legacy wrapper may include a legacy 
wrapper component coupled to a component adapter which, 
in turn, may be coupled to a legacy adapter via a legacy 
integration architecture. In this aspect, the legacy adapter 

5 may also coupled to the legacy system. As another option, 
the component adapter may also reformat call parameters of 
the message into an acceptable format for the legacy system. 

As an additional option for this aspect, the legacy wrapper 
component may also include a pure legacy wrapper com- 
ponent. As even a further option to this a^ect, the legacy 
wrapper component may include a hybrid legacy wrapper 
component. Also, the interfacing may further include: send- 
ing a message from the cUent to the legacy wrapper com- 
ponent via the component integration architecture; sending 
the message via the component adapter to the legacy inte- 

15 gration architecture; forwarding the message to the legacy 
adapter; formatting the message to match an application 
program interface (AH) of the legacy system; executing 
calls on the legacy system based on the formatted message; 
executing function of the calls and returning results to the 

20 legacy adapter, legacy integration architectine, component 
adapter, and legacy wrapper component which reformats the 
results; and forwarding the reformatted results to the client 
via the component integration architecture. 
Legacy systems pose a unique situation for developers of 

25 component-based solutions. Commonly hosted on 
mainframes, Legacy Systems often commimicate through 
proprietary protocols, have no standard data or process APIs 
and don't integrate easily with component based systems. 
How does a developer access a Legacy System in a 

30 component-based solution? 

A legacy system is an existing system that does not 
conform to the technology, architecture and standards of the 
current project. A large IBM 3090 Mainframe running 
programs to calculate automobile insurance rates is an 

35 example of a Legacy System, It is large, very important to 
an insurance company, and nms on older, proprietary hard- 
ware. 

Legacy Systems generally utilize different communica- 
tion protocols than those used by newly developed compo- 

40 nent systems. As a result, communicating between a newly 
developed component and a Legacy System is very dif&cult. 

FIG. 78 depicts the communication difficulties associated 
with Legacy Systems 7800 attempting to communicate with 
a client 7802 via a component integration architecture 7804. 

45 The newly developed application (client and components) 
communicates through a different protocol than the existing 
Legacy System. FIG. 78 illtistrates heterogeneous Interfaces 
from Components. 
Legacy Systems are critical to an organization and usually 

50 represent a significant investment. They are tightly con- 
trolled to reduce the incidence of system failures and clients 
may be unwilling or unable to replace these older systems. 

New applications could be developed on the mainframe 
system, however, this generally is not considered strategic 

55 and takes a lot of time and effort. Organizations want to add 
new functionality (new processes) without investing in the 
old legacy system. 

As a result, the current Legacy Systems represent signifi- 
cant investments, are often crucial to a business and aren't 

60 easily replaced. Investing in new Legacy applications isn't 
practical or strategic and Legacy Systems canM communi- 
cate with newer componentized systems. 

Therefore, the component-based solution should use a 
Legacy Wrapper to communicate with the existing Legacy 

65 Systems. The Legacy Wrapper is a component built to adapt 
the front end of a legacy system to the rest of the component- 
based solution. , 
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This solution encapsulates the concerns of a Legacy 
System away from the new application. It allows other 
components in the solution to communicate with the legacy 
component ia the exact same manner as the rest of the 
component-based solution. Further, this solution can also be 5 
used to partition the existing Legacy System functionality; 
FIG. 79 illustrates homogenous interfaces from components 
7900 which rectify the problems with Legacy Systems 7901 
attempting to communicate with a client 7902 via a com- 
ponent integration architecture 7904. 
Benefits 

Reuse. The Legacy Wrapper pattern allows reuse of an 
existing Legacy System. New component applications 
can be developed that leverage the rich store of busi- 
ness processes and data that already exist on the Legacy 
System, 

Migration. Allows for slower migration of functionality 
from the Mainframe to components. By continuing to 
use the functionality of the existing legacy system^ the 
immediate need to build the same functionality in a 
pure component-based solution is lessened. ^ 
Encapsulation. Provides a separation of concerns between 
the new system and the Legacy System. By encapsu- 
lating the Legacy System, the impact of host changes is 
largely limited to the Legacy Wrapper. ^ 
The implementation of Legacy Wrapper is usually very 
specific to the type of Legacy System it is integrating. The 
implementation in this section attempts to give a high level 
overview of the components of typical legacy systems. 

FIG. 80 shows how a Legacy Component is integrated ^ 
into a component-based model 8000. 

The upper part of FIG. 80 depicts the main units 8002 of 
a component-based solution. The lower part of the picture 
depicts the Legacy Component 8004 in greater details. 

The following is a description of the participants in the 
upper portion of FIG. 80. 
The Client (8006) is the application running on the user's 
machine. It is responsible for XJl presentation, local 
business objects, and communication using cUent resi- 
dent proxies. ^ 
The Component Integration Architecture (8008) is the 
component that allows clients to communicate and 
remotely invoke functions on the server components. 
Typically this is based on some middleware standard 
(e.g., CORBA or MTS). 45 
The Components (8010) in this FIG. 80 r^resents the 
server components. These are the business entity com- 
ponents and the business process components. They are 
invoked from the Client via chent proxies. 
From the outside, the Legacy Component 8004 looks 50 
identical to any other component. However, internally is 
performs a very specialized function. 

The lower part of FIG. 80 expands the Legacy Component 
8004. The expansion shows the individual elements, which 
comprise the Legacy Component 8004. These elements are: 55 
The Legacy Wrapper Component (8012) is responsible 
for presenting the same functionality provided by the 
legacy system to the rest of the component-based 
solution. Other components of the new component- 
based solution will interact and communicate with this eo 
component. Although this component wraps the exist- 
ing legacy system, it should behave as any other 
component in the newer solution. 
The Component Adapter (8014) is a custom component 
responsible for the translation from the Legacy Wrap- 65 
per Component to the particular implementation of the 
Legacy Integration Architecture. 
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The Legacy Integration Architecture (8016) is responsible 
for sending and receiving messages between the server 
and host machines. This architecture is usually based 
on some specific communication implementation. 
Examples of this include message queues and common 
databases accessible by both legacy systems and 
component-based solutions. 

The Legacy Adapter (8018) is a custom component 
responsible for translation from the particular imple- 
mentation of the Legacy Integration Architecture to the 
Legacy System. 

The Legacy System (8020) is the existing system that will 
be accessed by the newer component-based solution. 
Changes to the Legacy System should be minimized 
when accommodating the new component-based solu- 
tion. 

The application on the host is responsible for translating 
messages between the Legacy Integration Architecture and 
the Legacy System, For example, the application must know 
how to format calls to CICS appropriately, as well as 
interpret results and reformat them in a way appropriate for 
the Legacy Wrapper server component. 

The degree to which the wrapper components are spe- 
cialized to partition the functionality of the existing legacy 
system can vary. 

Pure Legacy Wrapper Component 

One type is the Pure Legacy Wrapper Component. This 
component simply adapts the legacy system to the new 
component-based solution. No new business processes are 
added. The interface methods on the Legacy Wrapper Com- 
ponent "pass through" to the legacy system, as shown in 
FIG. 81. FIG. 81 illustrates Legacy Wrapper Components of 
a Pure Legacy Wrapper Component including a Legacy 
Wrapper Component 8112, a Component Adapter 8114, a 
Legacy Integration Architecture 8116, a Legacy Adapter 
8118, and a Legacy System 8120. 
Hybrid Legacy Wrapper Component 

Another type of Legacy Wra^)per Component is the 
Hybrid component. FIG. 82 illustrates a Hybrid Component 
type of Legacy Wrapper Component. As shown, the hybrid 
includes a Legacy Wrapper Component 8212, a Component 
Adapter 8214, a Legacy Integration Architecture 8216, a 
Legacy Adapter 8218, and a Legacy System 8220. 

It is a mix of legacy system adapter and some new 
business processes built in a single component. Some of the 
interfaces 8222 of the wrapper component 8212 "pass 
through" to the legacy system, while other interfaces com- 
municate with objects, which may in turn call the legacy 
system. 

There are potentially more variations, including use of an 
Event Service to allow the mainframe to initiate work from 
the wrapper components. 
Example 

FIG. 83 shows an abstract example of the control flow in 
a Legacy Component. Although, the example is at a very 
high level, it should provide some insight as to how the 
Legacy Component functions and how it invokes work on 
the legacy system. 

From the example of FIG. 83, the following steps are 
shown: 

1. The Client component wants to invoke some 
functionality, which is located on the legacy system. The 
Client sends a message via the Component Integration 
Ardiitecture (e.g. ORB) on the way to the Legacy Wrap- 
per Component. 

2. The Component Integration Architecture (e.g. ORB) 
forwards the call to the appropriate Legacy Wrapper 
Component, 
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3. The Legacy Wrapper Component sends the call via the 
Component Adapter to the Legacy Integra tion Architec- 
ture. When necessary, the Component Adapter reformats 
the call parameters into an acceptable format for the 
Legacy System. 

4. The Legacy Integration Architecture receives a call for the 
host43ascd Legacy application and forwards it to the 
Legacy Adapter. 

5. The Legacy Adapter receives the message from the 
Legacy IntegratioD Architecture and formats it to match 
the API of the Legacy System. It makes the appropriate 
calls on the Legacy System. The Legacy System executes 
the function and returns the results to the Legacy Adapter 

6. The Legacy Adapter receives the results and returns them 
to the Legacy Integration Architecture. 

7. The Legacy Integration Architecture receives the result 
and forwards it to the Legacy Wrapper Server Component 
through the Component Adapter. 

8. The Legacy Wrapper Component receives the result, 
reformats the parameters for the component system and 
forwards it to the Component Integration Architecture. 

9. Finally, Component Interaction Architecture receives the 
result and forwards it to the Client. 

Collaborations 

Message Queued Legacy Integration is a specific imple- 
mentation of this pattern. It uses message queues as the 
legacy integration architecture. 

Adapter (from the Gamma book Design Patterns) 
describes at a more abstract level how to convert the 
interface of a class into another interface that clients expect. 

Proxy — ^This pattern is documented in Design Patterns by 
Gamma, Helm, Johnson and Vlissides. The proxy pattern is 
often used to communicate with server components in a 
distributed environment. The Proxy would be used to com- 
mimicate across the Component Integration Architecture to 
a Legacy Wrapper. 
Altematives 

Screen Scraping is a more specialized version of legacy 
wrapping. It describes how to convert a user interface to that 
of the server (i.e., the legacy system in this case). In this 
solution, the host-based application generates 3270 type 
screens and then passes them to QCS. The advantage of this 
solution is that it is non-invasive to CICS and reacts as if it 
were just another terminal interacting with QCS. This may 
be necessary with legacy systems which must be leveraged, 
but can not be modified and provide no common API set. 
Locally Addressable Interface 

FIG. 84 illustrates a flowchart for a method 8400 for 
delivering service via a locally addressable interface. In 
operation 8402, a plurality of globally addressable interfaces 
and a plurality of locally addressable interfaces are provided. 
Access is allowed to a plurality of different sets of services 
from each of the globally addressable interfaces and the 
locally addressable interface in operation 8404. Each inter- 
face has a unique set of services associated therewith. In 
operation 8406, the globally addressable interfaces are reg- 
istered in a naming service for facilitating access thereto. 
Use of the locally addressable interfaces is permitted only 
via the globally addressable interfaces or another locally 
addressable interface in operation 8408. 

In an option, the use of the locally addressable interfaces 
may be facilitated by structured-based communicadon. As 
another option, the access may be allowed via a customer 
interface proxy, a customer server and a database of the 
globally addressable interface. 

In one embodiment, a request may be received by the 
customer interface proxy for a reference to one of the locally 
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addressable interfaces. The request may then be forwarded 
across a network to the database of a server of the globally 
addressable interface. Also, data from the database may be 
returned in response to the request. Additionally, an object 

5 may be instantiated and populated it with the data by the 
server of the globally addressable interface. The object may 
also be associated with one of the locally addressable 
interfaces. Also, the locally addressable interface may be 
forwarded to the globally addressable interface. As even a 
further option, a reference may be forwarded to the locally 
addressable interface across the network and to the customer 
interface proxy. In addition, the use of the customer interface 
proxy may be also used to access the locally addressable 
interface across the network. 
In a client-server environment, a client makes requests of 

1^ Services on a Server. In such an environment, how might a 
Server expose its services for use to a cUent in a tightly 
controlled manner? 

Quite often a component wants tight control over the 
visibility of its interfaces or does not have a need to make its 

20 interfaces widely available. Examples of such situations 
include: 

Security — A component may provide multiple interfaces, 
some of which have sensitive operations that should not 
be exposed to all clients. For example, an insurance 

25 company's customer service desktop application gets 
faU access to all interfaces and services on a Customer 
component, but an Independent Agent application has 
restricted access to services. 
Interface Design — From a desigp standpoint it may make 

30 sense to limit access to some interfaces. For example, 
a system operations interface might allow clients to 
query Server components for the mmiber of requests 
being serviced, or disable future requests on a particular 
Server. In this type of situation, it's best to limit access 

35 to the appropriate user group. In this case, the opera- 
tions tools specifically designed for administering a 
system. 

Large number of interfaces — If the component design 
cafls for a large number of interface instances (objects), 
40 then it would be detrimental to use the GAI pattern. The 
sheer number of interfaces could overcrowd and over- 
burden the Naming or Trader service. The Naming or 
Trader service would slow down as it searched its large 
list of entries. Additionally, the system would slow 
45 down as every client attempted to access the Naming or 
Trader service for every interface. 
Thus, it*s sometimes best to keep interfaces with limited 
appeal out of a Naming or Trader Service. 
No need — ^If a particular interface or service only has one 
50 client, why bother registering it globally? It doesn't make 
sense and causes additional administration. 

FIG. 85 illustrates Problems with Globally Addressable 
Interfaces in a system 8500 including clients 8502 and 
servers 8504 with a plurality of interfaces 8506. 
55 The last couple of points are quite common for stateful 
components. The above samples clearly do not call for the 
GAI pattern — an alternative manner of making interfaces 
available to clients is required. 
Therefore, the Locally Addressable Interface pattern 
60 should be used to control access to interfaces in an efiBcient 
manner. 

FIG. 86 illustrates the manner in which the present 
invention uses a Locally Addressable Interface 8600 to hide 
functionality and lessen the load on the Naming or Trading 
65 Service 8602. 

All components maintain a Globally Addressable Inter- 
face 8604 This interface is registered with a Naming or 
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lYader service 8 6 02 and can have any of its services 
accessed by any client on the network. The services on a 
GAI 8604 are generally stateless and potentially shared by 
many clients. 

Locally Addressable Interfaces 8600 are not registered 
with a Naming or Trading service 8602 and can only be 
obtained through a Globally Addressable Interface 8604 or 
another Locally Addressable Interface 8600. 

FIG. 87 illustrates the manner in which the present 
invention obtains a Locally Addressable Interface 8700. 

Globally Addressable Interface 8702 services typically 
are used to obtain Locally Addressable Interfaces 8700 by 
providing some key information to the service, trigger 
global changes to all of the component's member objects, or 
to obtain component-maintained data that is not represented 
by a Locally Addressable Interface 8700, 

It is important to note that member business objects are 
never directly exposed to the client but, rather, communi- 
cated with thix)u^ a component interface (global or local). 
This allows for changes to be made to the internal structure 
of the component without disturbing the way a client inter- 
faces with the component. Encapsulation is preserved. 
Benefits 

Tight control. Servers providing LAIs have fill control to 
determine which clients will receive them. This control 
could, for example, be based on client type, access 
rights or server load. 

No central bottleneck. The pattern does not rely on a 
centralized service to hand out interfaces. This leads to 
a scalable architecture that can handle many interface 
instances. 

Useful for stateful components. Stateful components 
often contain many objects, each accessed through a 
separate interface instance. The LAI pattern is very 
useful in such circumstances. 
Complex server side relationships. The LAI pattem is 
better for managing complex object relationships than 
most alternatives. If an object is associated with a lot of 
other objects (an order holds a customer and an address 
and a line item etc.), it isn't practical to copy all of the 
objects to the client. 
The following is a message trace diagram depicting the 
interactions associated with a Locally Addressable Interface. 

The Message Ttace diagrams depict a common Client- 
Server scenario. The Client would like to interact with a 
specific Customer on the Server. The client requests a 
Locally Addressable Interface to a Customer Object on the 
Server and communicates with that object. 

The scenario was broken into two message trace dia- 
grams. The first message trace sets the stage for the second. 
In the first message trace, the Server registers a Globally 
Addressable Interface with the Naming Service. The Glo- 
bally Addressable Interface will be used to get the Locally 
Addressable Interface. 
Assumptions 

CORBA ORB connects Client and Server 
CORBA Naming Service used to lookup GAIs 
FIG. 88 illustrates the method in which the present 
invention registers and then locates a Globally Addressable 
Interface 8800. The various steps shown in FIG, 88 are set 
forth hcreinbclow. 
Collaborations 

la, "Bind" the interface name (Customer Interface) with 
it's Remote Object Reference (network location) in a 
Naming Service. This will allow clients to "lookup" the 
interface. Once the Interface is registered in the Nam- 
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ing Service, it has become globally addressable. Any 
client can find the interface and access a operation. 

2. The client instantiates a Proxy (Customer Interface 
Proxy) to the Customer Interface on the Customer 

5 Server. 

3. The Proxy "looks up" the network location of the 
Customer Interface. It makes a request of the Naming 
Service. It requests the network location of the Cus- 
tomer Interface. 

4. The Naming Service returns the Remote Object Ref- 
erence (network location) for the Customer Interface. 
The Proxy now has all the information it needs to 
access an operation on the Customer Interface. 

The second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and instantiates an object with the data. 
A Locally Addressable Interface to the specific Customer 
object is then returned to the Client. The Ghent can then 
directly access the specific Client through the Locally 
Addressable Interface. 

FIG. 89 ilustrates the manner in which the present inven- 
tion uses a Globally Addressable Interface 8900 to obtain a 
Locally Addressable Interface 8902 to a specific Customer 
^ Object 8904. Note the steps set forth below. 
Collaborations 

5. The Client asks the Customer Interface Proxy for a 
reference to a Locally Addressable Interface for Cus- 

3Q tomer 1234. 

6. The Customer Interface Proxy forwards the request 
across the network to the Customer Interface. 

7. The request is forwarded to the Customer Server, The 
Customer Server requests the customer data from the 

35 Database. 

8. The Database returns the customer data for Customer 
1234. 

9. The Customer Server creates instantiates an object and 
populates it with the ciistomer data. The Customer 

40 object is associated with a Locally Addressable Inter- 
face (Update Interface). 

10. The Locally Addressable Interface is forwarded to the 
Customer Interface. 

11. The Customer Interface forwards a reference to the 
Locally Addressable Interface, across the network and 
back to the Customer Interface Proxy. 

12. The Customer Interface Proxy instantiates an Update' 
Interface Proxy with the reference to the Update Inter- 

50 

13. The Customer Interface Proxy forwards the Update 
Interface Proxy to the Client, 

14. The Client sends a new address for the customer to the 
Update Interface Proxy. 

55 15. The Update Interface Proxy forwards the information 
across the network to the Update Interface. 
16. The Update Interface forwards the new address to the 
Customer Object. The Customer Object updates its 
address based upon the new information. 
60 Collaborations 

Proxy — ^The proxy pattern is generally used to commu- 
nicate from a Client to a Locally Addressable Interface on a 
Server. 

Interface — The Interface pattern defines methods or func- 
65 tions or services rather than implementation. The Interface 
pattern is expanded upon by the Locally Addressable Inter- 
face pattern. 
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Globally Addressable Interface — ^Locally Addressable 
Interfaces are private interfaces that aren't easily located. 
Generally, a well-known interface (like a Globally Addres- 
sable Interface) is used to find a LAI . A Client can easily find 
and access a service on a Globally Addressable Interface and 
request a reference to a Locally Addressable Interface in 
return 

Structured Based Communications — Often times, a client 
Deeds to display data in a UI for a user (e.g. Customer 
Information, Order Information, etc.). When communicating 
through a Locally Addressable Interface, this data is trans- 
mitted from the Server to the Client using Structure Based 
Communication, 
Alternatives 

Globally Addressable Interface, The Globally Address- 
able Interface pattern is both a collaborating and alternative 
pattern. It can be used to retrieve information from Servers 
instead of Locally Addressable Interface — the right choice 
will depend on the context. 
Null Structure 

FIG. 90 aiustrates a flowchart for a method 9000 for 
communicating a null value. A query is first communicated 
in operation 9002 &om a first system to a second system to 
determine whether a data structure is a null value. Next, in 
operation 9004, a response to the query is received from the 
second system indicating whether the data structure is a null 
value, A request for the data structure is sent firom the first 
system to the second system in operation 9006 only if the 
response indicates that the data structure is not a null value. 
Subsequently, the data structure is received from the second 30 
system in operation 9008. 

As one option, the response may be a Boolean indication. 
As another option, the response may be determined based on 
an attribute of the data structure. As a further option, the data 
structure may represent a set of a plurality of values. Also, 
the first system may, optionally, be a client and the second 
system is a server. 

When transmitting data across a network between a client 
and server application, the middleware's "type system" does 
not always support null values. How can a remote service 
send or receive null values over a communications medium 
that does not support them? 

It is expected that distributed Business Components will 
collaborate with other Business Components via some sort 
of communications medium. Communications between 
components is not usually handled by the components 
themselves but rather by some communications middleware 
(like an object request broker, or ORB). 

A "null" value is a frequently used value in object-based 
systems. A "null" represents the empty set. It is often 
returned from a service that is unable to find the requested 
elements or is used as an optional parameter in a distributed 
service. For example, a Client might request all the custom- 
ers with a last name of "Smith." If no Customers exist with 
a last name of "Smith," a "null" value would be returned. 

Some legacy systems return -999 or 0 when no data 
exists. This is not an ideal solution as the system is using 
data to represent non-data. What if -999 or 0 are valid 
responses to a request? Instead, a "null" could be used to 
better represent this case. A "null" value provides extra 
flexibility since a specific data value need not be reserved to 
represent the empty set. 

However, middleware cannot represent every data type 
that exists in every language. Since middleware is "language 
neutral", it can only represent the least common denomina- 
tor of every language accessible via the middleware. Due to 
this constraint, "null's" often can not be represented in 



35 



224 



middleware. FIG. 91 illustrates the problem associated with 
sending a NULL across many types of middleware 9100, 

A system should be able to take advantage of this impor- 
tant value and use middleware that may not support it. 

Therefore, use the Null Structure pattern to pass a struc- 
ture with an is Nufl attribute across the middleware. Unlike 
a "null", a structure can be passed across the middleware. 

FIG. 92 ilustrates the manner in which the present inven- 
tion passes a "nxill" structure across the middleware 9200. 

The extra attribute on the structure then determines 
whether or not the stracture represents a "null'* value. The 
structure can be queried to determine whether or not it 
represents a "null" value. FIG. 93 depicts conversations 
9300 with a ^'nuU" data structure 9302. FIG. 94 depicts 
conversations 9400 with a non-"nuIl" data structure 9402. 

The is Nufl attribute could be added as shown in the IDL 
example below. 



structure contmct 
{ 

boolean isNull; 
long buyerldentifier; 
Long scUerldentifier, 
double rate; 

}; 

Benefits 

Flexibility. Tins pattern allows for "null" values to be utilized by 
distributed components. 



The following example assumes a CORBA implementa- 
tion. In order to pass Null Structures across an ORB, a 
stracture must be defined in the ORB's interface definition 
language (IDL). The following IDL defines a structure that 
will represent an Integer or a "null." 
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struct Commonlnteger 



{ 



long value; 
boolean isNull; 



In the code that prepares the data to be sent over the ORB, 
a dieck of the data is made and the structure is populated 
appropriately. If it is null, the is Null flag is set, otherwise it 
is cleared. Refer to the following code example: 



public CommonlDteger oonvertIntegerForORB([nteger aninteger) 



{ 
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Commonlnteger integerStructure « 
if (aninteger -- null) 



new CormnQnIntegei( ); 



{ 

} 
else 

{ 



integerStructtire.isNull - true; 



} 



intcgcrStructureasKull « &lse; 
integerStructure. value « anInteger.intV^lue( ); 

} 

return integn'Structure; 



The receiving code that obtains the data from the ORB 
docs the same conversion in reverse as shown in the method 
below: 
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pt^lic biteger conveitIntegcrFroinORB(CoinmoDlnteger 

anlnlegerStmcture) 

{ 

lateger anlnteger « null; 

if (anIntegeiStiucture.ifiNull — false) // stnictuie not null 
{ 

anlotegei « new IntegCT(anIntegeiStnictuie. value); 

} 

return anlateger, 

} 



Collaborations 

Proxy. A Proxy is a placeholder that can accept requests 
meant for another object This is typically used in distributed 
systems when one component wants to send a request to 
another. Thus, a proxy is often used to make request of 
servers that may return null structures. 

aient-Server. Client-Server is a type of architecture that 
separates of Qient portion of an application from the 
business logic or database portion of an application. When 
implementing a Client-Server appKcation, the Client and 
Server often communicate across a middleware (like 
CORBA) that doesn't support "nulls." 
Alternatives 

Invalid Value. Determine an "invalid value" for each data 
type in the particular application. Return the "invalid value" 
when ever a null should be returned. 
Paging Communication 

FIG. 95 illustrates a flowchart for a method 9500 for 
transmitting data from a server to a client via pages. In 
operation 9502, pages of data sets are built from data in a 
database of a server. Upon receipt of a first request from a 
client for the data in the database of the server in operation 
9504, a first one of the pages of the data sets is sent to the 
client over a network in response to the first request in 
operation 9506. When a second request from the client for 
the data in the database of the server is received in operation 
9508, a second one of the pages of the data sets is then 
transmitted to the client over the network in response to the 
second request in operation 9510. 

ITie second request may be sent to the server with an 
identifier of a last entry of the first page. Also, a size of the 
data sets of the pages may be defined dynamically. As an 
option, the pages may be displayed by the cUent upon receipt 
from the server. Also, a size of the data sets of each of the 
pages may be determined based on a user interface of the 
client As another option, a size of the data sets of each of 
the pages may be determined based on an amount of data 
capable of being displayed at once by the client 

In a client-server environment, a client often needs to 
display or process a long list of data. Finding and transmit- 
ting this list of data can take a long time and negatively 
impact the user's response time. How can a client and server 
interact to improve the user's response time when retrieving 
a large list of data? 

The speed with which a UI can respond to a "user 
initiated" request is important. This is generally called the 
UI response time and is an important attribute of every 
applicatioa FIG. 96 depicts the response time 9600 for a 
User Interface 9602 to display a list of customers in a fist box 
9604. 

Users expect an "acceptable" level of UI response in their 
applications. Applications that don't meet this criteria, will 
not be successful. 

Many UIs allow \isers to query databases for lists of data. 
In FIG. 96, for example, the user clicks the "Get Customers" 
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button to initiate a database query. The query will retrieve 
every customer from the database and the UI will display the 
customers in a list box. The user can then scroll through the 
data and select a particular entry for further investigation. 
^ FIG. 97 shows a request that returns a large amount of 
data. As shown, in a three-tiered client-server environment, 
each query must travel from the client UI 9700, across a 
network 9702, to a Server 9704, and eventually to a Data- 
base 9706. Then, the result of the query must travel all the 
way back to the client. 

When the query results in a large amount of data, the time 
to search the database and return the data across a network 
can become prohibitive. As a result, the UI response time 
will quickly degrade to an imacceptable level. 

To make things worse, the average user only looks at half 
of the data returned from the database. The user is just as 
likely to find their data in the first half of the list as the 
second half of the hst. As a result, the user may wait a long 
20 time for data that is not used. 

FIG. 98 shows a graphical depiction of a paging commu- 
nication pattern 9800. 

Therefore, provide Paging Commimication between the 
client and server tiers of an application. Paging Communi- 
^ cation describes a pattern for transmitting a large amount of 
data while maintaining an acceptable UI response level. 

Rather than send all of the data at one time, a subset or 
"page" 9802 of data is transmitted. When the client needs 
more data, another "page" 9802 of data is transmitted. This 
^ continues until the client has seen enough data or all the data 
has been transmitted. 
Benefits 

More Responsive UI. This pattern improves upon the 
35 user's response time. The server only retrieves and 
transmits a "page" of data at a time. This is a lot faster 
than retrieving and transmitting all of the data at one 
time. The pattern breaks-up the total search and trans- 
mission time into smaller page-sized chimks. This 
40 greatly improves upon the user's perceived perfor- 
mance. 

Additionally, the Server searches the database for a 
"page" of data at a time until the user finds what they 
are looking for. As a result, unless the needed data is in 
45 the last page of data, the search is limited to a portion 
of the total search. 

Configurable Page Size. The page size can be "timed" to 
best fit the application. As a result, the page size can be 
altered to best fit a particular network, application 
design, etc. 

Stateless Servers. The paging mechanism can be managed 
from the client-side requester. Thus, this pattern can be 
used with stateless servers just as easily as with statefiil 

55 

UI 'I\mable. The page size can be changed to match a 

particular User Interface. 
List Box Friendly. A list box can only display a limited 
amount of data at one time. As a result, it isn't as 
60 important to have all of the data immediately available 
for the fist box. The List box can display a page of data, 
and then request additional pages of data as the user 
scrolls through the list. 
Scenario: A user is searching for a particular customer. 
65 The user doesn't remember the exact name of the customer, 
but the user believes they will recognize the name when they 
see it. Thus, the user requests a list of all customers. 
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^ Technical Parameters 
Static Page Size«4 

List Box caD only display 2 lines of data at a time. 

FIG. 99 illiistrates a message trace diagram showing the 
interactions between a Client 9900 and a Server 9902 using 5 
Paging Communication to satisfy the previously mentioned 
scenario. 
Definitions 

Starting Key 

The Starting Key is the initial starting point for the search. 
The database will begin searching for data (customers 
in the message trace above) at the Starting Key, An 
example starting key could be "A*". 

Last Found Key 

' 15 
Hie Last Found Key is used to request subsequent pages 

of data firom the Server and the database. The "last 

found key" defines the starting point for the next data 

request. The Server will begin searching for data at the 

"last found key" and continue until it has retrieved a ^ 

full "page" of information. 

When all of the data has been retrieved from the Server 
and Database, the Last Found Key is left blank. This 
notifies the Client that all the data has been sent. 

Intermediate Page 25 

An intermediate "page" is returned for every request but 
the last. When a client receives an intermediate page 
and a "last found key", the client knows more "pages" 
of data exist on the server. 

In order to obtain an intermediate "page," a "last found 30 
key" must be passed from the client to the server. When 
the Server has retrieved a full "page" of data, the new 
"last found key" is saved. It is then passed bac^ with the 
intermediate "page." The new "last found key" defines 
the starting point for the next data request. 35 

Last Page 

When the Server has retrieved all of the data meeting the 
search criteria, the Server builds the last "page." When 
the last page is retumed to the client, the "last found 
key" is left blank. This notifies the client the search is ^ 
complete and no more data matching the search exists 
on the Server. Note that the last page is usually smaller 
than the other pages. 

Empty Page 

When no data are selected from the search criteria, the 
server builds an empty page signaling to the client no 
more data exist on the server. 

Static or Dynamic Page Size 

The page size can be defined statically or dynamically. 
The message trace diagram in FIG. 99 depicts a static 
page size. 

If you'd like a dynamic page size, the client must pass an 
additional parameter with each request to the Server. 
The additional parameter would be the page size. 

The steps associated with FIG. 99 will now be set forth. 
Collaborations 

1. The user "clicks" the "Get Customers" button on the 
User Interface. The Client UI makes a gctAllCustomcrs 
request of the Server and passes a Starting Key as a 60 
parameter. Since the user wants to view all of the 
customers, a Starting Key of spaces is used. Message 
sent-g6tAllCustomers(" "); 

2. The Server receives the request fi-om the CUent. The 
Server realizes the Starting Key is blank and knows this 65 
is a new request. Thus, the Server requests first four 
customers (the page size) from the database. 
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3. The database returns the first four customers (Albert 
Abraham, Ned Abraham, Sally Abraham and Alice 
Allen) and a "Last Found Key" ("Alice Allen") to the 
Server. The "Last Found Key" denotes the last entry 
found during the search. It vfin be iised for subsequent 
searches. 

4. The Server bmlds a page with the four customers 
retrieved from the database. TTie Server returns the 
page and the Last Found Key to the Client. 

Page lype-Intermediate 

Page-"Albert Abraham", "Ned Abraham", "Sally Abra- 
ham" & "Alice Allen" 
lastFoundKey-"Alice Allen" 

The Client receives the "page" of data. The Client sends 
the data to a UI List Box for viewing by the user. The User 
can see the first two customers (Albert Abraham, Ned 
Abraham). 

The User clicks the "scroll down" arrow twice and can 
now see two additional customer (Sally Abraham, Alice 
Allen). 

5. The User clicks the "scroll down" arrow again. No 
more data exists on the Client so the Client must 
request another page from the server. The Client UI 
makes a getAllCustomers request of the Server and 
passes the Last Found Key of Alice Allen. Message 
sent-getAllCustomers("Alice Allen"); 

6. The Server receives the request from the Client. The 
Server requests the next four customers (page size) 
after Alice Allen. Message scnt«getPageOfcustomer 
("Alice Allen") 

7. The database returns the next four customers (Jason 
Allen, Fred Allen, Sam Allen & Zack Allen) and a "Last 
Found Key" ("Zack Allen") to the Server. 

8. The Server builds a page with the four customers 
retrieved form the database. The Server returns the 
page and the Last Found Key to the Client. 

Page Type-Intermediate 

Page«"Jason Allen", "Fred Allen", "Same Allen" & 

"Zack Allen" 
lastFoundKey-"Zack AUen" 

The Client receives the "page" of data. The Client sends 
the data to a UI List Box for viewing by the user. The 
User can see the first two customers and one new 
customer (Alice Allen, Jason Allen). 

The User can now scroll through the next three customers. 
When scrolling past customer Zack AUen, the Client 
will request another page of data from the Server. It will 
follow the same basic pattern as described in steps 5-9. 

Eventxially, the end of the list of Customer will be reached 

n-3. Once again, the client clicks the "scroll down" arrow 
and no more customers exist on the client. The Client 
must request another page from the server. The Client 
UI makes a getAllCustomers request of the Server and 
passes the Last Found Key of Jim Ziegler. Message 
sentagetAllCustomers("Jim Ziegler"); 

n-2. The Server receives the request from the Client, The 
Server requests the next four customers (page size) 
after Jim Ziegler. Message sent-getPageOfcustomer 
("Jim Ziegler") 

n-1. The database can only find two more customers. The 
database returns the final two customers (Sam Segler 
and Ziggy Ziegler) and no Last Found Key. 

n. The Server builds a page with the two remaining 
customers retrieved from the database. The Server 
returns the page and the blank Last Found Key to the 
Client. 
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Page lypeoLast Page In distributed systems with many clients, it is important to 
Page»"Sam Ziegler", "Ziggy Ziegler" establish connections with remote servers in an efficient 
lastFoundKcy-" " manner In a manner where clients evenly utilize the avail- 
Hie Client receives the final "page" of data. The Client able servers. How can this be performed in a consistent 
sends the data to a UI List Box for viewing by the user 5 manner for all clients? 

The User can see the following two customers (Jim In production systems it is quite common for long-lived 

Ziegler, Sam Ziegler). clients to "stay up" for days and interact with a collection of 

Ihe User cUcks the "scroU down" arrow once and can difiFerent servers. Oftentimes, a client process will establish 

now see the final two customers (Sam Ziegler. Ziggy connections to the same type of server a bunch of times 

Ziegler) in the List Box 10 lifetime. The lifetimes of the cUent and its servers 

„ , \ « V I « *L 11 J 1 are often different as a result of server maintenance and 

Subsequent "clicks on Uie scroU down arrow no longer ^^jj^^^ However, such failures should have minimal impact 

request daU from the Server. The Client knows (due to ^„ ^^^^ qj^^^ j„ ^ ^^^^ ^ 

the blank last found key) that it has already received all q^^^,^ Addressable Interface (GAI) from a naming or 

°^ A^'^f T^^der Service (see GAI Pattern). 

Additional Details „ , ^ ^ ^ ^ • , " A GAI retrieved by a cUent will usuaUy go through three 

Context isn't generally stored on the Semr >yhen miple- ^ases: 1) Initial retrieval of a GAI from the TVader Service 

mentmg Pagmg Commumcation. As a r^uit, u is miportant ^ suteequently wrapped up in a proxy, 2) Invocations 

to request a mmimum coUecUon of data from the server. „f businesses functions supported by the GAI and 3) Release 

Most of the relational database are using a count mechamsm „f ^his often means a long-Kved client will 

that defines the maximum number of data to search. That 20 „ jedly ask the Trader Service for the same type of 

minimize CPU and memory usage. interface during its lifetime. 

As explamedmthe example, page size may be adapted to illustrates repeated requests to the Trader Ser- 

the client requuements however that does not mean the ^^^^ j^,^^^^^ „^ ^^j^^^^ ^jg^^^^^j 

page size must exactly fit the widget size. Ideally the chent necessary 

applic^ion will anticipate future user actions and request 25 Repeatedly requesting the same interface from a Trader 

more an one page. Service is neither efficient or necessary. However, the Trader 

LoUaboratic^s . ^ ^ , . , Service does maintain load balancing information and alio- 

Prcxy-TTie Proxy pattern is often Jjsed to communicate ^^^^ ^usy interface at any given time. Thus, some 

between Chents and Server in a dislnbuted environment. A j reallocation. 

Proxy IS often used to make requests for a "page of data 30 Therefore, use a Refreshable Proxy Pool mechanism that 

rom a erver. standardizes the usage, allocation and replenishment of 

Interface Contol Model-The ICM pattern addresses the ^^^^ ^ ^ ^j^^^j.^ ^ ^^^^ p p„^, 

separation of the Interface (Viewing portion) fi:om the ^ t,^^^ p^^^^^ ^^.^^ ^ 

ContrclfromtheModel(thedataporUon)manapphcaUon. „f ^ ^o^^ trader Service. Naming 

Paging CommunicaUon is often used when implementing 3S g^^j^^j ^ j, ^^ p^^^^ ^ 

this separaUon of fiinctionahty. A user through the Interface ^^^^^ ^^ ^^^^ ^ 

uses the pattern to retneve large lists of data from the Model ^ p^j ^ j ^ 

for viewing. p 

Globally Adtossable Interface-GlobaUy Addressable p,Q iUustrates how a pool 10200 can be created that 

Interfaces are often used to obtain a Page of data from a 40 ^^^^ proxies 

2te "arvK^"'"^ ^ ' ^ to balance the system load evenly, the Proxy Pool 

emaives should implement a Load Balancing approach (e.g. Round 

Pagmg wvb Server aching-This pattern builds upon ^^^^^ ^ ^^""^ ^ 

the Pagmg Commumcation pattern. Rather than querying ^^^^ ^ j ^ ^ "retirement age." The 

tne _database tor a page ot intormaUon. the Server would 45 ..^jirement age" determines the time to refresh a given 

retneve all of the data at one time. Then the Server would d*«^,. wtu^^ T d^«., *♦ T«i,^ 

, J . ^. . . Proxy. Wnen a Proxy reaches its retirement age, it is taken 

pass the data to the Ghent one page at a time. * r *u i j i ^ -*u * ui n * j n 

D f K. Ki p p 1 out of the pool and replaced with a freshly allocated Proxy, 

1 nn ^r^/ . ^ u .4^ ixa^ ^ ^^^^^ the Proxy Pool is refreshed regularly with new 

FIG. 100 Illustrates a flowchart for a method 10000 for ^^^^^^^^ ^J^^ ^^^^^ Service Hie retirement 

mterfacing a nammg service and a client wi^ the naming 50 ^.^^^ ^elps dynamically balance the systems load, 

service allowing access to a plurahty of different sets of Benefits ^ j 

services from a plurality of globally addressable interfaces. „ - . i.,- i.. 

In operation 10002, the naming service calls for receiving Performance Estabhshmg connections to servers will 

locations of the globdaddressS,le interfaces. As a result of ^^^.^^^ tune because chents will go to the trading 

the calls, proxies are generated based on the received 55 „ service less otten. 

locations of the global addressable interfaces in operation Balanced Load. This ensures all chents are implementing 
10004. The proxies are received in an allocation queue ^^^^^^Sy ^^^^B available servers, 
where the proxies are then allocated in a proxy pool (see Standard. One single approach to pooling increases main- 
operations 10006 and 10008). Access to the proxies in the tainability and predictability across the enterprise and 
proxy pool is allowed for identifying the location of one of 60 decreases confusion. 

the global addressable interfaces in response to a request ^se of use. Oient developers do not have to design and 

received from the client in operation 100010. implement their own version of pooUng. 

The proxy pool may employ load balancing. As another Maintenance. This mechanism allows for ccntraUzed 

option, the proxies in the proxy pool may be renewed based development. When a bug is found it can be fixed and 

on an age thereof. As a third option, a handle may interface 65 distributed to all build centers, 

the proxy pool and the client. This handle may additionally Dynamic. Client threads will not have to worry about 

interface a plurality of the proxy pools and the chent. allocating retired or bad proxies. 
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Robustness. By pooling GAI location information, clients 
are less susceptible to Trader Service failxire. This is 
becaxise the Proxy Pool can operate using the GAIs it 
has information on for as long as those references main 
valid. 

The Proxy Pool should be packaged and distributed to 
client developers so that it is non-intrusive and easy for them 
to use. 

Parameters such as pool size and retirement age should be 
configurable. 

The client thread using the proxy should not pay a penalty 
for pooling or allocation. 

Hie pool should recover gracefully from server failure. 

The pool should recover gracefully from Trader Service 
failure. 

FIG. 109 illustrates the implementation of a Refreshable 
Proxy Pool 10300. The Refreshable Proxy Pool is based on 
a pool-queue approach. In this design, the pool holds allo- 
cated proxies 10302 while the queue allocates and replen- 
ishes the pool with proxies. To handle the allocation and 
replenishment, a worker or allocation thread 10304 runs on 
the queue and makes calls to the Trader Services as needed. 

There can be numerous proxy pools, but this implemen- 
tation supports typed pools Using C++ templates, i.e., each 
pool will only contain proxies of one type. This allows the 
client to create a class that is passed to the proxy pool and 
supports client specific properties in the pool such as pool 
size, retirement age, etc. Also, due to synchronization issues 
with the rest of the architecture, there can be only one 
allocation queue. 

aients who wish to use a pooled proxy will create a 
handle as a wrapper. This handle wrapper takes care of the 
problems associated with sharing resources across threads 
such as lazy initialization, reference counting, allocation, 
and de-allocation. 

Handles are classes that abstract the users away from the 
implementation. Handles are generally stack based and exist 
for the lifetime of a method invocation or an object. The 
handle destructor insures that the ujiderlying proxy is deref- 
erenced. 

Suggested Classes 

FIG. 104 illustrates the class relationships between the 
patterns primary classes. 



Class 



Desaq)tiott 



PoolcdPraxy (10402) 



ProxyPool (10404) 



AllocadonPool (10406) 



This is Oie base dass for the pooled proxy. It 
actually acts as a wrapper for a Proxy and 
maintains all usage and reference counting 
information. 

This is the proxy pool, where clients go to 
retrieve a proxy. It should be thread-safe in 
that miiltiple threads are autamatically syn- 
chronized. This pool should only contain 
valid proxies that have been allocated by 
the AllocationPool. When a proxy is 
requested, the usage count is incremented. 
After the *^isage" passes retirement age, the 
proxy is remove from the pool and placed 
back into the allocation pool. 
Hiis is the pool that actually docs the proxy 
allocation. This pool is populated with un- 
allocated proxies and a "reader" thread will 
allocate them. Since there will only be one, 
this class should be implemented as a 
Singleton. This pool however can allocate 
proxies of any type. 
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-continued 



Class 



Description 



ProxyHandle^> (10408) 



10 



This is the Handle that clients should use to 
manage pooled proxies. The handles must 

use a static ca8t^> (C-m- template) to 

retrieve the correct proxy. T is defined by a 
client ten^late instantiation, and assumes the 
client knows exactly what type of proxy the 
pool is actually holding. Clients must take 
care to assure that pools only contain proxies 
of one type. 



Collaborations 

15 Globally Addressable Interface — ^This is a pattern for 
making interfaces publicly available. Distributed connec- 
tions to Globally Addressable Interfaces can be pooled using 
the Refreshable Proxy Pooling pattern. 
Proxy — ^This pattern is documented in the book "Design 

20 Patterns'* by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distnbutcd environment. Proxies are pooled 
using the Refreshable Proxy Pool pattern. 

Trader — ^The Trader service defines how distributed archi- 

25 tectures locate components based on the types of services 
they provide. The allocation queue interacts with a Trader 
Service to allocate the correct type of proxy. 

Naming — The Naming Service provides a mapping 
between names and object references. A Naming Service 

30 could be used to store the GAI references that the Refresh- 
able Proxy Pool pattern requires. 
Alternatives 

Single Use — ^As opposed to pooling connections to a 
remote server a cUent can request a new connection each 

35 time a GAI is needed. This would work best when a client 
infrequently needs GAIs. 

Proxy Pool — ^This pattern addresses the pooling of prox- 
ies without periodic refreshing. It is a simpler version of the 
Refreshable Proxy Pool that may be of use when server load 

40 is fairly constant. 
Self-describing Stream 

FIG. 105 illustrates a flowchart for a method 10500 for 
providing a self-describing stream-based communication 
system. Messages are sent including data between a sending 

45 system and a receiving system in operation 10502. Meta- 
data is attached to the messages being sent between the 
sending system and the receiving system in operation 10504. 
The data of the messages sent from the sending system to the 
receiving system is translated based on the meta-data in 

50 operation 10506. The meta-data includes a first section that 
identifies a type of object associated with the data and a 
number of attribute descriptors in the data. Also included is 
a second section that includes a series of the attribute 
descriptors defining elements of the data. 

55 As an option, the sending system and receiving system 
may each be equipped with logic for interpreting the meta- 
data of the messages. As another option, the elements may 
be defined in terms of size, type, and name. Versions of the 
present invention include a version where one of the systems 

60 may be an object-based system and one of the systems may 
be a non-object-based system, a version where both of the 
systems may be object-based systems, and even a version 
where both of the systems may be non-object-based sys- 
tems. 

65 Stream-based communication is a very effective pattern 
for relaying data, data structures, and meta-data. Meta-data 
is information about the data, such as data structure, data 
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types, etc. using a shared, generic format. How can the 
message format be shared between systems so as to create 
the most flexible stream-based communication mechanism? 

Often, it is determined that a stream-based communica- 
tion mechanism should be used to transport information 
between systems. Stream-based communication is a pattern 
where information is transported from one system to another 
system using a simple stream and a shared format that relays 
both the data and meta-data information. 

FIG. 106 illustrates two systems 10600 communicating 
via Stream-Based Communication 10602 and using a shared 
generic format to relay the meta-data information. 

However, when implementing Stream-based Communi- 
cation 10602, a number of factors influence the method for 
enabling each system with a "shared format." The "shared 
format" provides the meta-data information needed to inter- 
pret the raw data in a stream. This shared format is like a 
secret decoder ring for systems sending aad receiving mes- 
sages. It allows the systems to convert structured data 
(objects, strings, etc.) into raw data and raw data back into 
structured data. This is needed to transmit the structured data 
across the network. 

Many additional factors influence the detailed design of 
this communication mechanism. Some systems support 
volatile and constantly changing object models, data models 
and data structures. In these systems, flexible, de-coupled 
comm^mication is extremely important. 

In a constanfly changing system, a statically defined 
"shared format" doesn't work very well. Every change to the 
object model, data model of data structure causes a reimple 
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section, and a data section. The header portion contains 
generic information about the message. It contains such 
information as the type of object, the number of attributes 
descriptors, the target environments, etc. The attribute 
descriptors section contains a series of attribute descriptors 
that define the various data elements of the information. The 
nxunber of these attribute descriptors is usually defined in the 
header section. The last section contains only data. 

FIG. 109 illustrates the manner in which a message 
language defines how to parameteiise the meta-data 10900 
and put it on the stream. 
Benefits 

Greater FlexibiUty. Because the information about the 
structure of the data has been parame tensed and stored 
as additional data within the message, changes to the 
data structure would have no effect on this interface 
mechanism. This means the interface mechanisms will 
not need to be re -designed/re -built/re -tested/re- 
deployed, etc for each change in meta-data. 
Interfacing systems are better de-coupled. Because the 
message format is embedded in the actual stream, this 
format does not need to be stored or kept in synch 
across different systems. It can be "discovered" at 
run-time when the interface is invoked. 
For object-based systems, the implementation is quite 
straightforward. Simply make each object responsible for 
implementing streaming behaviors based on the format and 
message language. Each object should know how to get and 



mentation of the "shared format." Each reimplementation 30 parse its attribute values onto a stream as string values 

(streamOn) and each object class should know how to parse 
attributes off of a stream and put these values into a new 
instance of the object (streamOfi^. 

Below is an example of a Self -Describing stream. It is 
used to stream an object's information from an object-based 
system to a non-object system. 

FIG. 110 illustrates a Customer object 11000 in an object- 
based system 11002 streaming itself into a stream 11004, the 
stream 11004 being sent to a non-object system 11006, this 
stream 11004 being read and the data inserted into a rela- 
tional database 11008. The steps illustrated in FIG. llO will 
now be set forth. 

1. The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with 
an empty stream as the argument *aStream'. The Cus- 
tomerObject "streamOn:" method goes through each of 
the object's attributes and parses each value as a string 
onto the stream. 

In the Java pseudo-code below, the message language 
defines the format of the header, the format of the 
attribute descriptors, and the dehmiter used in the 
parsing. 



results in a redesign, recompile, and retest of the changed 
code. 

FIG. 107 illustrates an object-based system 10700 with a 
frequently changing object model 10702 communicating via 
Stream-Based Communication 10704. 

FIG. 107 depicts a constantly changing system. Initially, 
the object-based system 10700 is designed to send Poodle 
objects through a stream to a non-object system 10702. As 
time passes, the system requirements change. Now, the 
object-based 10700 system mMSt send German Shepherd 
objects through a stream to the non-object system 10702, If 
the "shared format" for converting dog objects to raw data 
is inflexible, this will break the system. 

In cases like this, it would be better to implement a 
communication mechanism or "shared format" thai can 
better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a 
stream that contains message data AND descriptive meta- 
data. Then use a message language to read the formatting 
information and meta-data off of the stream. 

FIG. 108 illustrates a stream-based message that contains 
both message data 10800 and descriptive meta-data 10802. 

FIG. 108 depicts a message sent using a Self-Describing 
Stream. The first 30 bytes contain descriptive meta-data 
10802. This meta-data 10802 describes the formatting of the 
"real" data 10800 in the remainder of the message. It 
describes the data type, attribute names, location in the 
message, etc. of the "real" data 10800 in the message. TTie 
remaining 70 bytes are the "real" data 10800 transmitted 
between the two systems. 

Additionally, each system must implement a message 
language. The message language defines the rules for writ- 
ing and interpreting the descriptive meta-data. It describes 
how the meta-data is parametarised and embedded in the 
message. 

These Self-Describing messages usually contain three 
distinct sections: a generic header, an attribute descriptors 
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Note: Assume that "asString( converts the receiver to a string and that 
"padWit]iSpace8( )^pads the string with spaces and makes the string the 
length specified. 

/*• Stream my attribute values on aStream *•/ 
public void StreamOn (Ou^utStream aStream) 
{ 

// CREATE THE HEADER 

aStieam.write('CUSTOMER *); // This is a customer object 

aStream. wiite(* 003'); // with three attributes 

aStream. write(* 001'); // this is the format version 

// DESC31IBE EACH ATTRIBUTC 

aStream. write(Stream.Delimiter); 

aStream.write('NAME '); 

aStream. wiite('SrO *); 



06/17/2004, EAST Version: 1.4.1 



us 6,636,242 B2 



235 



236 



-continued 



•continued 



aStrcaiii.writtC'010*); 
aStrcain.write(Stream. Delimiter); 
aSticam.writeC*SEX '); 
aStrcam.writeCSTO '); 
aStreain.writ6('007'); 
aStrcam.witc(Strcam.Dcliinitcr); 
aStreain.write('AGE *); 
aStrcam.write('NUM 
aStrcam.write('O03'); 

// WRITE OUT THE ATTRIBUTE VALUES AS DATA 
aStrcam.writc(S trcain.Delimiter); 

aStrcam.write(this.getName( )^String( ).padWitliSpaces(10)); 
aStream.write(this.getSeac( ).asStrmg( ).padWithSpaces(7)); 
aStrcam.'writc(this.gctAgc( ).a5String( ).padlWthSpaces(3)); 
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♦** FIND WHAT BYre THE DATA STARTS AT AND SETTEIE 
INDEX 

MOVE (IT-ATTRIBUrE-DESCRtPTOR-SIZE • WS-HEADEK-NUM- 

OF-ATTRIBUTES) 

TO WS-INDEX. 

PARSE THE APPROPRIATE OBJECT STRUCTURE OFF OF "* 

THE STREAM **♦ 
IF WS-HEADER-OBJECT-TYPE EQUALS "CUSTOMER" THEN 

PERFORM 1000-EARSE-CUSTOMER-OTlEAM THRU 

1000-PARSE-CUSTOMER-STREAM-END. 
ELSE IF WS-HEADER-OBJECT-TYPE EQUALS "EMPLOYEE" 
THEN 
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2. The stream is then put into a message communication 
mechanism like MQSeries or MessageQ and sent to the 
non-object system. 

3. Once at the non-object system, interface code reads the 
stream, parses the values off, converts and moves the 
values into a copybook with the appropriate structure, 
and saves the information in relational database. A 
pseudo-COBOL example is listed below. In reality, this 
interface code would be more dynamic than depicted in 
this example. 
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DATA DFVISION. 
FD FILE-STREAM-IN 

RECORD CONTAINS 100 CHARACTERS 



WORKING-STORAGE SECnON. 

01 WS-HLE-STREAM-IN 

Ol WS-SHARED-FORMAT-HEARDER 

03 WS-HEADER-OBJECT-TYPE 

03 WS-HEADER-NUM-OF- 

ATTRIBUraS 

03 WS-HEADER-VERSION-OF- 
FORMAT 

Ol WS-SHARED-FORMAF- 
ATTRIBUTE 

03 WS-AITEUBUTE-NAME 
03 WS-AfTRIBUTE-TYPE 
03 WS-AFTRIBUTB-SIZE 
01 TEMP- VARIABLES 
03 WS-INDEX 

01 WS-CUSTOMER 
03 WS-NAME 
03 WS-SEX 
03 WS-AGE 

88 IX-HEADER-StZE 

88 IT-ATTRIBUTE-DESCRIPTOR-SIZE 

88 IT-DEUMINATOR 

88 IT-CTRING 

88 IX-NUMBER 

PROCEDURE DIVISION. 



PIC X(100). 

PIC X(10)- 
PICX(7). 

PIC 999. 



PIC X(5). 
PIC X(5). 
PIC 999. 

PIC 9999. 



PIC X(10). 
PIC X(7). 
PIC 999. 

FIX 99 VALUE 20. 
PIXX(l) VALUE 14. 
PIXX(l) VALUE «h 
PIXX(l) VALUE -STG". 
PIXX(l) VALUE -NUM". 
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OPEN IHE FILE STREAM AND READ IT INTO THE 
TEMPORARY *** 

VARIABLE WS-FILE-STTREAM-IN 
OPEN HLE-STREAM-IN. 

READ FILE-STREAM-IN INTO WS-FILE-STREAM-IN 

AT-END CLOSE FILE-STREAM-IN 

END-READ. 

*** MOVE THE HEADER INFORMATION INTO THE HEADER 
COPYBOOK" 

MOVE (WS-FILE-STREAM-IN FROM ZERO TO IT-HEADER-SIZE) 
TO WS-SHARED-FORMAT-HEADER. 



45 



50 



55 



60 



ELSE IF 
ELSE 

END THE PROGRAM 
RUN-STTOP. 
END-IF. 

IQOO-PARSE-CUSTOMER-STREAM. 

*** READ WHICH VARIABLE IT IS AND POPULATE THE 

CORRECT *** 

**• VARIABLES ♦** 

IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX +5)) - 

-NAME" 

THEN 

MOVE WS-INDEX TO START-INDEX. 

FIND THE DEUMINATOR AFTER THE NAME STRING AND 

*** 

♦** MOVE THE NAME VALUE INTO THE SEX VARIABLE * ** * 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FlLE-STREAM-IN AT INDEX) « LT- 
DELIMINArOR 
END-PERFORM. 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX) TO WS-SEX. 

PERFORM 1000-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE IF (WS-HLE-STREAM FROM WS-ff^DEX TO (WS-INDEX + 
5)) = -SEX- 
THEN 

*** FIND THE DEUMINATOR AFTER THE SEX STTRINO AND 
MOVE 

*** THE SEX VALUE INTO THE SEX VARIABLE 
MOVE WS-INDEX TO START-INDEX. 
PBRFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BY I 

UNTIL (WS-FlLE-STREAM-IN AT WS-INDEX) - IT- 
DEUMDSTATOR 
END-PERFORM 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX)TO WS-SEX 

PERFORM 1000-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX + 
5)) " "AGE" 
THEN 

***FIND IHE DEUMINATOR AFTER THE SEX STRING AND 
MOVE*** 

♦•-THE SEX VALUE INTO THE SEX VARIABLE 
MOVE WS-INDEX TO SiTART-INDEX. 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FILE-STREAM-IN AT WS-INDEJO - IT- 
DEUMINATOR 
END-PERFORM 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX)TO WS-SEX 

PERFORM lOOO-EARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE IF (WS-FILE-STREM FROM WS-INDEX TO (WS-INDEX 
+5)) - "AGF* 
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-continued 

THEN 

FIND THE DEUMINATOR AFTER THE AGE STRING AND 
*** MOVE THE AGE VALUE INTO THE AGE VARIABLE 
MOVE INDEX TO STAKT-INDEX. 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FILE-STSEAM-IN AT WS-INDEX) - LT- 
DEUMINATOR 
END-PERFORM 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX) TO WS-AGE 

PERFORM lOOO-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE 

PERFORM 2000-SAVE-CUSTOMER THRU 
2000-SAVE-CUSTOMER-END. 
END-tF. 

lOOO-PARSE-CUSrOMER-STREAM-EXrr. 
2000-SAVE-CUSTOMER. 

*•* CALL A SQL MODULE TO SAVE THIS INFORMAnON IN 
THE 

RElAnONAL DATABASE 
CAUL -SAVE-CUSTDMER-IN-DATABASE" USING WS- 
CUSTOMER 

2000-SAVE-CUSTOMER-END. 



Conversely, a stream could be created by a non-object 
system or another object system, populated with customer 
information, and sent to one's object-based system. Oace in 
the object-based system, the CustomcrObject could use a 
"streamOff: aSteam" method, instanciate a CustomerObject, 
and populate it with the appropriate attribute values. 
Collaborations 

Stream -based Communication. This is the parent pattern 
to the Self-Describing Stream pattern. In this pattern, infor- 
mation is transmitted using a simple stream and a shared, 
generic format The Self-Describing Stream is a more spe- 
cific implementation of Stream-Based Communication. 

Bridge (&om the Gamma book Design Patterns) describes 
a way to de-couple an abstraction from its implementation 
so that the two can vary independently. The Bridge pattern 
is often used to define collaborations between a business 
object and a format object while decoupling the business 
object &om its specific stream format. 

Abstract Factory (from the Gamma book Design Patterns) 
is a pattern for creating families of related classes. This 
could be used with the Bridge pattern to retrieve the format 
dynamically based on non-static information. 
Alternatives 

Fixed Format Stream — ^This pattern is a ^ecific variation 
of Stream-Based communication where the messaging for- 
mat is defined and stored on both the sending and receiving 
systems. 

Downloadable Format Stream — This pattern is a specific 
implementation of Stream-Based communication where the 
messaging format is stored at a central location and is 
downloaded by the communicating parties when needed. 
Stream-based Communication 

FIG. Ill illustrates a flowdiart for a method UlOO for 
providing a stream-based commimication system. A shared 
format is defined on interface code in operation 11102 for a 
sending system and a receiving system. A message to be sent 
from the sending system to the receiving system is translated 
based on the shared format in operation 11104. The message 
is sent firom the sending system and received by the receiv- 
ing system in operations 11106 and 11108. The message 
received by the receiving system is translated based on the 
shared format in operation 11110. 
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As an option, information in the translated message 
received by the receiving system may be stored in a rela- 
tional database. As another option, the shared format may be 
based on an order of attributes in the message. 
5 In one version, one of the systems may be an object-based 
system and one of the systems may be a non-object-based 
system. In another version, both of the systems may be 
object-based systems. In a third version, both of the systems 
may be non-object-based systems. 

In order to successfully transmit a formatted message, 
both the sending and receiving systems must understand the 
format and structure of the transmitted information. Some 
communications mediums, however, do not inherently trans- 
mit the formatting information with the data. How can 
information be easily communicated between systems when 
the communication mechanism does not inherently convey 
data structure or other meta-data information? 

For two systems to successfully communicate, they must 
tmderstand the structure of the data they are passing. The 
sending system needs to convert standard programming 
20 constructs (objects, structure, strings etc.) into bytes of data 
that can be transmitted along a network. The receiving 
system needs to receive the bytes of data on a wire and 
reconstitute it back into objects, structure, strings etc. 

Many communication mechanisms inherently provide 
25 this functionality to a software developer. CORBA and 
DCOM are two examples of this type of middleware. Using 
CORBA, one system can send a structure of information to 
another system. CORBA will convert the structtire into a 
network appropriate format, transmit it across the network 
^ and reformat it on the receiving end. 

Other types of middleware, however, do not provide this 
fiill range of functionality. Lower level communication 
protocols like TCP and UDP as well as higher-level proto- 
cols like HTTP and tehiet do not provide support for sending 
data structures. 

35 Additionally, popular message queuing software (IBM'S 
MQSeries and BEA Messaged) and many custom commu- 
nications mechanisms are lacking support for transmitting 
structured data across the network. 
These communication protocols do not inherently convey 

40 meta-data information. *Meta'-data is information about the 
data. Meta-data could describe the data structure (senders 
address in bytes 1-10, receivers address in bytes 11-20, data 
in 21-100, etc.), data types, etc. 
When the highest-level common communication protocol 

45. between two systems cannot convey this meta-data 
information, an alternative communication mechanism is 
needed. 

FIG. 112 illustrates how systems 11200, 11202 of the 
present invention communicate over a communication 
50 mechanism 11204 that cannot inherentiy convey meta-data 
information. 
How can they exchange structured data? 
In objea-based systems, issues with conveying meta-data 
are even more prevalent. Object-based systems often need to 
55 transfer object information across non-object communica- 
tion mechanisms (e.g. DCE, . . . ) or to non-object systems. 
Because neither non-object communication mechanisms nor 
the non-object systems tmderstand the notion of objects, 
how can the structure of the objects be meaningfully con- 
60 veyed? 

FIG. 113 is an illustration of an object-based system 
11300 conununicating with a non-object system 11302 tising 
a commimication mechanism 11304 that cannot convey 
meta-data information. 
65 How can they exchange structured data? 

Therefore, use Stream-based Communication to transmit 
information between systems. Stream the data between the 
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two systems and use a generic format to relay the infoima- 
tion and its associated meta-data between the systems. 

A stream is simply a buffer that data is "written to'' and 
"read from" in discrete quantities. The size of the buffer is 
predetermined and can be very small (i.e. one byte in length) 
or very large (i.e. a page). The buffer can*t hold objects or 
structures, but just raw data. Buffers are quite dumb and 
don't understand anything about their raw data. Thus, it does 
not have meta data for the information in the buffer. 

The "shared format" provides the meta-data information 
needed to interpret the raw data in the buffer. This shared 
format is like a secret decoder ring for systems sending and 
receiving messages. The sending system uses the decoder 
ring to convert objects, structures, etc. into raw data on a 
stream. The receiving system uses another decoder ring to 
reconstitute the raw data back into objects or structures. If 
objects aren't supported, the raw data is converted into a 
comparable format for use by the receiving system, 

FIG. 114 depicts an example of Stream Based Commu- 
nication with two disparate systems 11400, 11402 commu- 
nicating via stream-based communication 11404. 

In FIG. 114, the object-based system 11400uses a shared 
format (decoder ring) to convert an object into raw data. The 
raw data is then copied onto the stream. The stream then 
delivers the data to the Non-Object system 11402. The 
Non-Object system 11402 reads the raw data and reconsti- 
tutes the data using its shared format. 

In this example, the sending system is sending objects 
while the receiving system doesn't understand objects. Thus, 
the receiving system can only convert the raw data into a 
data equivalent of the object sent. 
Benefits 

Maintainability. When using this pattem, a shared, generic 
format is used to interpret the data. As a result, the two 
systems are de<oupled and less dependent upon each 
other. As long as the format remains unchanged, 
changes to the internal implementation of either system 
will not affect the other system. Maintenance of 
decoupled systems is easier 
Batch Compatible. Strings of data can be concatenated 
and transmitted as a group. This enables batch mes- 
saging (e.g. Request Batcher) and processing. 
Enables Lightweight Persistence. Stream-based commu- 
nication can be used to interface with a Ughtweight 
persistence mechanism. Objects, structures, etc. can be 
can be converted to raw data and streamed to a flat file 
for saving. At a future time, the file can be opened, the 
raw data can be streamed out of the file and reconsti- 
tuted into full blown objects or structures. 
The implementation of Stream Based Communication is 
very straightforward. Simply define interface code on the 
sending system that creates a stream and parses the data onto 
this stream using a format shared by the both the sending and 
receiving systems. On the receiving system, define interface 
code that reads the stream and, using the same shared 
format, parses the data off of the stream and into a data 
structure compatible with the receiving system. 

Ihe specific implementation of the formats can be, and 
most hkely will be, different from system to system but the 
actual format must be shared and should be generic between 
systems. Shared so that the information is accurately relayed 
and generic to keep the systems as de -coupled as possible by 
not exposing any implementation details of either system in 
the format. Further, this shared format can be implemented 
in a variety of places depending upon the specific require- 
ments of the interface. 

For object-based systems, make each object responsible 
for implementing streaming behaviors that use this shared 
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format. Each object should use the format as a map to parse 
the attribute values onto a stream (streamOn). Conversely, 
each object class should use the format as a map to parse its 
attribute values off of a stream and put them into a newly 
5 instantiated instance of the object (streamOff). 

In the example below, an object within an object-based 
system uses stream-based communication to stream its 
attribute values onto a stream. Then a communication 
mechanism transports the stream to a non-object system, and 
a non-object system reads the information off of the stream 
and inserts it into its relational database. 

FIG. 115 is an illustration of a Customer object 11500 in 
an object-based system 11502 streaming itself into a stream 
11504, the stream 11504 being sent to a non-object system 
11506, this stream 11504 being read and the information is 
inserted into a relational database 11508. 

1 . The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with 
an empty stream as the argument *aStream'. The Cus- 
tomerObject "streamOn:" method goes through each of 
the object's attributes and parses eadi values as a string 
onto the stream. 

The fixed format contract here is embodied in the order 
^ that this method parses the attributes onto the stream. 

A pseudo-code example in Java is the following: 
Note-Assume that "asString( )" converts the receiver 
to a string and that "padWithSpaces( )" pads the 
string with spaces and makes the string the length 
^„ specified. 



/* * Stream my attribute values on aStieam * */ 
public void streamOn (Outputs tieam aStream) 
{ 

aStieam.write(this.getName( )AsString( ).padWithSpaces(10)); 
aStrcam.watc(this.gctScx( )jisString( ).padWithSpaccs(7)); 
aStream. write(thU.getAge( ).asString( ).padWithSpacesC3)); 
} 



2. The stream is then put into a message communication 
mechanism like MQSeries or MessageQ and sent to the 
non-object system. 

3. Once at the non-object system, interface code reads 
45 through the stream, parses the values off of the stream, 

converts them to the appropriate types if required, and 
puts them in a copybook with the appropriate structure. 
In this example, the fixed format contract is embodied 
in the structure and type of the WS-SHARED- 
50 FORMAT-CUSTOMER working-storage copybook. 
Refer to the pseudo-COBOL example below. 

DATA DIVISION. 

S5 

FD FILE-STREAM-IN 

RECORD CONTABSfS 20 CHARACTERS 

WORKING-STORAGE SECTION. 
_ *** THIS COPYBOOK CONTAINS THE SHARED FORMAT OF 
^° THE 

CUSTOMER IN THE DADV STRUCTURE AND DMA TYPES 
01 WS-SHARED-PORMAT-CUSTOMER 
03 WS-SHARED-FORMAT-NAME PIC X(10). 

03 WS-SHARED-FORMAT-SEX PIC XC7). 

03 WS-SHARED-FORMAT-AGE PIC 999. 

65 THIS COPYBOOK IS THIS SYSTEMS VIEW OF A CUSTOMER 
01 WS-CUSTOMER 
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03 WS-NAME 
03 WS-AGE 
03 WS-SEX 

PROCEDURE DIVISION. 



PICX(10). 
PIC 999. 
PIC X(10). 



OPEN THE FILE STREAM AND PUTTHE CONTENTS IN THE 
*** WS-SHARED-FORMAT-CUSTOMER COPYBOOK 
OPEN HLE-STREAM-IN 

READ nLE-STREAM-IN INTO WS-SHARED-FORMAT- 
CUffTOMER 

AT-END CLOSE FILE-STREAHtlN 
END-READ. 

*** MOVE TEIE VALUES [NTO FROM THE SHARED FORMAT 
INTO 

*** rm WS-CUSTOMER VARIABLES. 
MOVE WS-SHARED-FORMAT-SEX TO WS-SEX. 
MOVE WS-SHARED-FORMAT-AGE TO WS-AGE. 
MOVE WS-SHARED-FORMAT-NAME TO WS-NAME. 

CALL A SQL MODULE TO SAVE THIS INFORMATION IN 
THE 

*** RELAnONAL DATABASE 

CALL '*SAVE-CUSrOMER-IN-DADVBASE" USING WS- 
CUSTOMER. 

STOP-RUN. 
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Conversely, a stream could be created by a non-object 
system (or another object-based system for that matter) 
and sent to one's object-based system. In this case, 
CustomerObject could use a "streamOff: aStream" 
method and instanciate a new instance of a aCustomer- 
Object and populate it with the appropriate attribute 
values. 



30 



Again, there are several variations of this pattern depend- 
ing upon what the specific requirements are. Some of these 35 expertise of a business object, the user must send a request 



FIG. 116 illustrates a flowchart for a method 11600 for 
efSciently retrieving data. A total amount of data required for 
an application executed by a client is determined in opera- 
tion 11602. In a single caU, the total amount of data from a 
server is requested over a network in operation 11604. All of 
the data is bundled in operation 11606 into a data structure 
by the server in response to the single calL In operations 
11608 and 11610, the bundled data structure is sent to the 
client over the network and the data of the data structure is 
cached on the client The cached data of the data structure is 
used as needed during execution of the application on the 
client in operation 11612. 

The data structure may be bundled on the server by a 
business object. In addition^ the business object may be 
instantiated by an action of the client. Also, the network may 
be at least one of a local area network and a wide area 
network. As a further option, the request may be adminis- 
tered by a proxy component. Further, the data structure may 
contain no logic. 

In a client server application, the client communicates 
with a server over a network. Depending upon the speed of 
the network and the number calls across the network, an 
application can experience performance problems. How can 
a client update a server while minimisdng the network traflSc 
and maintaining an acceptable level of system performance? 

Acceptable system performance is an important attribute 
of every application. When creating a client-server 
application, the performance of the network mtist be con- 
sidered during the design and development of an applica- 
tion. The speed at which data can be transmitted across the 
Local Area Network or Wide Area Network, can make or 
break a client-server application. 

In a typical three-tiered client-server application, the 
btisiness objects are maintained away from the users (Client) 
on separate Server machines. Whenever a user needs the 



across the network to the Server machine. 

FIG. 117 illustrates the manner in which a client 11700 
requests information from server objects 11702 via a net- 
work 11704. 

Depending upon the size of the message and the speed of 
the network, this could take a long lime. This is a reality of 
three-tiered client-server applications. 

When a client-server application is introduced to the 
world of distributed objects, the network can become an 



variations are further explained in the children patterns. 
Refer to Fixed Format Stream, Downloadable Format 
Stream, and Self-describing Format Stream. 
Collaborations 

Fixed Format Stream — ^This child pattern is a specific 40 
variation of Stream-Based communication where the mes- 
saging format is defined and stored on both the sending and 
receiving systems. 

Downloadable Format Stream — ^This child pattern is a 
specific variation of Stream-Based commimication where 45 even larger bottleneck. In a pure distributed object approach, 
the messaging format is stored at a central location and is the client is passed an object reference to a business object 
downloaded by the communicating parties when needed. on a server machine. The client then accesses the specific 

Self-Describing Stream. This child pattern is a specific business object over the network as if it resided on its local 
variation of Stream-Based communication where the mes- machine. Using this "ptire" distributed object approach, the 
saging format is parameterised and stored on the stream. A so application's calling pattern begins to look like the sche- 
message language is used to read and write the format of the matic of FIG. 118. 

message from the stream. FIG. 118 illustrates the method of the present invention in 

Structure Based Communication — ^This pattern uses a which a client 11800 requests attributes from a server object 
Fixed Format Stream to transmit data structure between 11802 via a network 11804. 
systems. It is often used to obtain data from a Server for 55 
display in a Client UI. 

Bridge (from the Gamma book Design Patterns) 
describes a way to de-couple an abstraction from its imple- 
mentation so that the two can vary independently. The 

Bridge pattern is often used to define collaborations between 60 single machine. Ignoring this reality may result in an imac- 
a business object and a format object while decoupling the ceptably slow application. 

business object from its specific stream format. On a very fast LAN where the number of network calls is 

Abstract Factory (from the Gamma book Design small, this calling pattem may be acceptable. On a slower 
Patterns) is a pattem for creating families of related classes, ' LAN, any WAN or when the number of network calls is 
This could be used with the Bridge pattem to retrieve the 65 large, this pattern wiU yield unacceptable network perfor- 
format dynamically based on non-static information. mancc. Something must be done to maintain an acceptable 

Structure-based Communication level of system response for the users. 



This is an excellent programming model that frees the 
developer to access local and remote objects in the same 
fashion. Unfortunately, it makes it easier for the application 
developer to forget about the physical realities of the net- 
work. A network call is always slower than a call within a 
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FIG. 119 ilustrates the transmitting of all data in a Data 8, The Client asks the Customer Proxy for the data assod- 

Structurc 11900 from a client 11902 to a server 11904 and ated with the Jimbo Jones object, 

visa-versa. As shown, to maximize the performance on the 9. The Customer Proxy forwards the request across the 

cUent, it is best to bundle all the necessary data into a single network to the Customer Component, 

data structure that can be transmitted as a structure across the 5 10. The Jimbo Jones object creates a data structure and 

network. populates it with its data. 

The Client would first determine the sum total of every- n. The Data Structure is passed across the network to the 

thing it will need from the business object on the Server Customer Proxy on the Client. 

machine. The Client makes a request for all of this data from 12, The Customer Proxy forwards the data structure con- 

the business object. The business object bundles all the data 10 taining Jimbo Jones' data to the Client component 

into a data structure and returns it to the client. The Client Participants 

will cache this data (using the Caching Proxy pattem) on its oient-llie "client" for the transaction. Tliis could be a 

bcal chent machme and use it as needed. ^ser Interface that displays customer data for viewing 

by a Customer Service Representative. 

Better System Performance-This pattern will improve 15 ^etwork-A LAN or WAN network that connects the 

the performance of an application by reducmg the ^^^^^ ^^^^^^^ Component, 

network traffic between the chent and the server. The ^ 

cHent makes one network request to retrieve all of the Customer Component— A server component that encap- 

data from the server. Regardless of the number of sulates the data for all of the customers in a system, 

displayable attributes the application will only make 20 Customer Component Proxy— A proxy to the Customer 

one network send. Component. Any request it receives^ it forwards across 

Without this pattern, the client could make a network send the network to the Customer Component 

for every attribute retrieval. If the user wants to retrieve Customer Proxy — A proxy to the Jimbo Jones Customer 

a customer's name, address and phone number, that Object Any request it receives, it forwards across the 

could result in three network requests (one for each 25 network to the Jimbo Jones Customer Object, 

attribute). Without this pattem, the network traffic can ACustomerStructure— A data structure. It contains the 

become prohibitive and the performance would suffer, data (but no methods) from the Jimbo Jones object. 

Stmcture Based Communication assumes a chent needs Database— Any relational database, 

informationfromanobjectthatexistsonaserver. Thus, this ^. , , ^, . . , t x. . 

pattern assumes the existence of an "interesting" object on 30 Object^An object that represents the Jimbo 

Jones customer. This object contains Jimbo Jones data 

the server maaiine. , , , . ^ , , 

*i- 1. *u J- 7» J «• * *• *• c and methods associated customer methods. 

Even though the finding and instantiating of a server ~^ i^vm^«j ^x^^v^u^y^L ix*vv^viw« 

object isn't part of this pattem, it does establish context and Sample Java Code 

sets the stage for the pattem. As a result, a message Uace following java example accompanies the previous 

diagram for finding and instantiating a particular object 35 message trace diagrams. The java code follows the same 

instance is shown below. This will set the stage for the scenario as the message trace diagrams, but it has been 

implementation of the Structure Based Communication pat- simplified in some areas. 

tern. The following snippet of code defines the data structure 

FIG. 120 illustrates the method in which a client 12000 ^ P^ss customer information, 

finds and instantiates a Customer Object from a customer 40 

component 12002. The various steps shown in FIG. 120 will 

now be set forth. ^^^.^ CustomerStmctuicC 

Collaborations string firstName, 

1. The client instantiates a Proxy (Customer Component string lastName, 
Proxy) to the Customer Component. The Client then asks 45 '^^^^ sUectNumbcr, 
the Proxy for Customer Jimbo Jones. 

2. The Customer Component Proxy forwards the request string state, 
across the network to the Customer Component string z^jCode) 

3. The Customer Component requests the information for 

Jimbo Jones from the database. 50 following block of code is the "main" routine for the 

4. TTie Database returns the data associated with customer ^Hent. Even though all distributed caUs are made through a 
_ ° - ^ . : proxy, the proxy code is not shown in this example. The two 

5. The Customer Server Component instantiates a customer ^j^^ encapsulate the details associated with dis- 
object usmg the Junbo Jones data from the database. ^ibuled network calls. 

6. The Customer Server Component returns a remote object ss 
reference to the "Jimbo Jones" object running on the 
Server. 

7. The Qient creates a proxy to the "Jimbo Jones" object // aient side code here, 
using the remote object reference. Mnia{ ) 

Now that a customer object (Jimbo Jones) exists on the 60 f, „ . „ * *v <^ . ^ 

1 ^ • • Create a Proxy to the Customer Component. 

server component. Structure Based Commumcation can be CustomerComponcntProxy aCuatomeiComponcntProxy - 

used to pass the needed data from the server to the client. new CuatomeiCon:^onentProxy( ); 

FIG. 121 ilustrates a Structure Based Communication that // Get a Proxy to the runbo Jones Customer 

builds upon the method of FIG. 120 and depicts the flow of '^^„p, .customerProxy - 

control durmg Structure Based Communication. The various 65 aCustomciComponcntPraxy.gctQistomcrC"Jimbo Jones"); 

steps shown in FIG. 121 will now be set forth. // Oct Customer data from the Customer Server 
Collaborations 
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-continued 



// Compoiieat(CaU across the aclwork) 
CustomeiSttucture aCiistomcrStructuic - 

aCiisto[neiPioxy.getCU8toineiAsStiuctuie( ); 
// Use the Customer data received in the 
// structure. For Example, display the data 
// structure data (aCustomcrStructuie) in a UI. 



} 



The following code is a sample Customer Server Com- 
ponent. The Customer Server Component is used to retrieve 
the data associated with ciistomer Jimbo Jones from the 
database. It also instantiates a customer object using the data 
retrieved from the database. 



// Customer Conqjonent Code here 
public dass CustomerOompoaeat 
{ 

// Put the data associated with a Customer Object 

// into a data Structure. This data structure 

// will be sent across the network to a client 

public Customer gctCu5tomcr(String aCustomerName) 

{ 

// Find the Customer in the database 



// Instantiate the Customer Object 
Customer aCustomer - new Qistomer(.. 

// Return a "remote object reference" to the 
// Jimbo Tones Customer object, 
return (aCustomer); 

} 

Finally, this is the code for the Junbo Jones Customer object 
// Customer object code here 
public dass Customer 

{ 

// Put the data associated with a Customer Object 
// into a data Structure. This data structure 
// will be sent across the network to a dient 
public CustomerStructure getCustomerA8Structure( ) 
{ 

CustomerStructure aCUstomerStructure » new 
CustomerSttucture( ); 

aCustamerStnictuie.ftistName » this.getFirstName( ); 
aCustomeTStiucture.lastName ■» this.getLastName( ); 
aCustamerStnicture.stxeetNumbcr « this.getStreetNumbei( ); 
aCustomerStructure.street » this.getStreet( ); 
aCustomerStructure.city - this.getCity( ); 
aCustamerStructuicstate « this.getState( ); 
aCustomerStructure.z^Code = this.getZipCode( ); 
return aCustomerStructure; 

} 

// Getters and Setters for all attributes 
// (code not shown here) 



} ' . 

Note: The "Main** code cxan^le above obtains a Proxy to customer 
"Jimbo Jones" and then a Structure of data through the proxy. Hie oode 
was written for ease of understanding, but causes two calls across the 
networL tn reality, it is preferred to perform both functions using one 
network call. Limiting the number of network calls will improve system 
performance. The recommended code might look something like this: 
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// Qeate a Proxy to the Ctistomcr Component 

// (same as above) 
5 CuatomeiComponcntProxy aCustomeiComponentProxy - new 

CustomeiComponeiilProxy( ); 
// Get a Proxy to the Jimbo Jones Customer 
// object 

// AND 

// customer data at the same time. 
10 CustomerProxy aCustomerProxy; 

CustomerStructure aCustomerStnicture = 

aCustomerComponcntProxy.getCustomcTData("Jimbo Jones", 
aCustomerProxy); 



^5 Collaborations 

Proxy — ^This pattern is documented in the book "Design 
Patterns" by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distributed environment. The Proxy pattern 
is often used to retrieve data structures from a server 

^ component. 

Cached Proxy — ^This pattern is documented in "The 
Proxy Design Pattern Revisited" section of the Pattern 
Languages of Programming Design 2 book. ACached Proxy 
caches data locally on the client. SUiicture Based Commu- 

^ nication uses and builds upon this pattem. 

Globally Addressable Interface — ^This pattem often works 
in conjunction with Structure Based Communication. 
Oftentimes, a Globally Addressable Interface is used to 
obtain Structures of data for display on a Client. 

30 Locally Addressable Interface — ^This pattern can also be 
used in conjunction with Structure Based Communication, 
After establishing a relationship with an LAI, a cUent may 
obtain data from the Server object using Structure Based 
Communication. 

35 Alternatives 

Distributed Objects — The "pure" distributed object 
approach is an altemative to Structure Based Communica- 
tion. Using this pattem, individual objects are queried for 
each piece of information needed by a client. 

40 Presentation Services (1000) 

Presentation Services enable an application to manage the 
human-computer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 

45 of processing. The Presentation Services forward on the user 
requests to business logic on some server. Typically, Pre- 
sentation Services are only required by client workstations. 

In addition to Presentation Services on the client, some 
business logic wLU usually reside on the client as well to aid 

50 the Presentation Services. Even on thin clients some sort of 
validation logic is usually included with the Presentation 
Services. A quick review of the Gartner Group's five styles 
of client/server computing help to illustrate this. 
FIG. 122 shows the Gartner Group's Five Styles of 

55 Client/Server Computing 12200. 

The way that Presentation Services interact with client- 
side business logic is very important to the overall scalabil- 
ity and maintainability of the application. An application's 
business logic is expected to be highly reusable, even on the 

60 client. If business logic is coupled with the Presentation 
Services too tightly, it will be very difficult to separate and 
reuse the business logic if the Presentation Services ever 
need to be altered (not an uncommon occurrence). 

The patterns in this section help to guide application 

65 architects on strong, proven techniques to safely integrate 
client-side business logic with an application's Presentation 
Services. The Activity pattem lays the groundwork for 
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separating the Presentation Services and biisaness logic on Often these user interfaces will be changed over time to 

the client by assigning noa-prcscntatioa logic to a type of fit user's changing needs. While the tasks completed by the 

object called an Activity. The Yicw Configurer pattern he^)s user may not change, the interface to complete those tasks 

to assign new views with their appropriate Activity. Finally, will need to. Windows users will want to move to the Web, 

the User Interface Validator pattern describes how to imple- 5 Web users will want to move to handheld devices. The 

ment customizable, extendable validation logic on a user presentation code should be able to be changed without 

interface. causing a rewrite of the business logic on the client. 

Activity Therefore, bundle business logic executed on the client 

FIG, 123 illustrates a flowchart for a method 12300 for separate from the presentation logic. This new type of class 

providing an activity module. A server and a presentation is an Activity, 

interface of a client are interfaced to permit the receipt of An Activity is responsible for: 

requests for service from the presentation interface of the managing client logical units of work 

client in operations 12302 and 12304. A portion of the maintaining client representation of a business model 

requests are handled on the client in operation 12306, In vahdation across multiple interfaces (complex business 

operations 12308 and 12310, another portion of the requests logic) 

are forwarded to the server for further handling purposes and 15 ^^^^ exception handling 

changes are effected m the presentation interface. • *• -^u j *i. 

~r^i ... n _ A commumcatioD with server and other services 

A plurality of presentation interfaces may be interfaced, * * • • 

Optionally, a model may be interfaced for management creatmg other AcUviUes 

purposes. With such an option, the model may further tnggenng events intended to be "caught" and acted on by 

include a proxy. As another option, errors and exceptions 20 presentation logic 

may also be handled. As a third option, events intended to be An Activity resides between the actual user interface and 

received may be triggered by the presentation interface. business model and server components as shown in the 

Many client/server applications maintain some amount of Entity Relationship diagram below: 

business logic on the client. How can an application repre- FIG. 125 illustrates an activity entity relationship dia- 

senl and reuse "chent-side" business logic across multiple, 25 gra™. 

volatile user interfaces? While any user interface maintains a reference to the 

Imagine a typical cLent/server system design. In almost Activity 12500 it provides an interface 12502 for, the 

all cases, a typical system executes data access logic on the Activity is unaware of what (if any) interfaces exist on it. 

server and presentation logic on the cUent, business logic is This decoupling allows for a large amount of flexibility with 

split across both the client and server. The majority of this 30 the interfaces to an application. Multiple types of interfaces 

business logic is maintained on the server. This logic is can exist on a single type of Activity. Code is reused and 

represented by various components and business objects that oonc is lost if presentation logic is replaced with something 

can communicate with each other to complete a variety of different. 

system use cases. While a user interface can communicate directly with its 
The client, on the other hand, is mostly responsible for 35 associated activity, an activity should never direcdy corn- 
supporting user interactions with the system. To be municate with any of its interfaces. This would set up a 
successful, the client must also execute some degree of dependent relationship that would reduce the flexibility of 
business logic. While this can vary from implementation to activity. Instead, an activity can communicate to its 
implementation, some categories of logic are invariably interfaces through an event mechanism. Interfaces are set up 
located on the client. Tliis includes simple data validations, 40 as dependents of the activity and the activity sends events to 
representing data structures and relationships, error and all of the interfaces on it. Each interface can decide how to 
exception handling, and communications with the server. handle the event. 

To complete a single use case, the client may need to FIG- 126 illustrates a roles and responsibilities diagram, 

interact with a number of server components. From the Benefits 

user's perspective, one unit of work is being performed but 45 Maintainability. By separating the presentation and non- 
it may involve multiple, discrete interfaces and multiple presentation logic, the client is easier to understand and 
server invocations. Some business logic is required to man- maintain. 

age the complex flow to complete this unit of work. For Reuse. The presentation layer may be replaced or reused 

example, suppose a use case for a network inventory man- without affecting the non-presentation logic, 

agement system is "Add Network Card". This may require so FIG. 127 iUustrates a typical implementation between a 

the user to input information in three or four screens and user interface and its activity. 

client communication with more than one server component. The diagram shows the various "layers" of interaction 

Managing this flow is not the responsibility of the presen- where the lightest shaded boxes are the presentation, the 

tation logic but still needs to be executed on the client. next darkest is the activity, and the darkest is the component 

The system may also require a number of interfaces to 55 (proxies 12700). 

complete the same use case. Depending on the user category A user request is captured and processed by the presen- 

executing the use case, the interface may be a PC, a tation object (NetworklnventoryUserlnterface 12702). In 

handheld device, or a telephone. Even on the same type of this case, the processing involves simple validation (format 

device, the interface may differ depending on the user and "is nufl" checking). 

category. Some users may want to access the application via 60 The presentation object then copies its data into a struc- 

a standard Windows interface while others may want to ture representing some business entity (aNetworkltem 

access it via a "web-centric" interface (internet browser). In 12704) and passes it to the activity 12706. The presentation 

all of these cases, the unit of work to be completed by the object then triggers the activity to start its processing of the 

user is not changed and should be reused. new network item. 

FIG. 124 illustrates multiple interfaces to an application 65 The activity then performs possibly more complex vah- 

12400 including a handheld device 12402, a desktop PC dation and communicates with the server components to 

12404, and a telecommunications device 12406. complete the use case. 
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Collaborations 

Facade — The Activity acts as a Facade to all of the server 
components by coordinating a user interfaces interaction 
with them. 

Separation of Cdncem — Dividing defined responsibilities 5 
into separate classes (presentation logic into UI classes and 
client-side business logic into activity classes). 

Observer — An activity's interfaces are observers of that 
activity. 

User Interface Validator 

FIG. 128 illustrates a flowchart for a method 12800 for 
structuring validation rules to be applied to a user interface 
for maximimi maintainability and extensibility. In opera- 
tions 12802 and 12804, a plurality of user interface widgets 
are provided along with a plurality of validation rules which 
govern use of the user interface widgets. A user is allowed 
in operation 12806 to select the validation rules to associate 
with the user interface widgets of a first user interface. The 
validation rules of the user interface widgets of the first user 
interface are automatically associated across a plurality of 
separate different user interfaces in operation 12808. 20 

The validation rules may be created at the time the first 
user interface is created. As another option, the vaUdation 
rules may be implemented by a different class for each type 
of validation. As a further option, an indicator may be 
displayed upon one of the validation mles being violated. 25 
Additionally, each validation rule class may extend an 
abstract validation rule class that defines what types of 
widgets are supported. Also, a request for the vahdation 
rules may optionally be received from one of the user 
interfaces. 30 

How can you structure validation rules to be applied to a 
user interface for maximum maintainabiUty and extensibil- 
ity. 

Imagine a typical Windows or web-based client/server 
application. In most cases where a "windows'* type of user 35 
interface is provided, an application supports some business 
rules by validating data entered by the user. A common 
example of this is checking the format of data in an entry 
field or ensuring that a required field is not left empty. 

The business rules supported by user interface validation 40 
is usually somewhat limited. The scope of these rules is 
generally constrained to checking if a field is empty, check- 
ing the format of a field (date, time, numeric, currency, etc.), 
and checking if a field has alpha-characters, numeric- 
characters, or both. In addition, due to fact that many 45 
widgets provide constraints through their own form (list 
boxes, radio buttons), the types of widgets that require this 
type of validation checking is also somewhat limited (text 
fields, editable combo boxes, etc.). 

FIG. 129 illustrates widgets with their validation require- so 
ments 12900. 

Because this type of validation will most likely be 
required across all of an application's user interfaces and the 
fact that the types of validation rules and widgets needed to 
validate are limited, this behavior is a strong candidate for ss 
a framework. 

Hie framework would provide a common approach to 
validating user data across all of an application's user 
interfaces. Rules would be applied consistently throughout 
the application. While some common validation rules would 60 
be provided, the fi:amework needs to allow their behavior to 
be modified (overridden) and make it easy for new rules to 
be added. 

Finally, both immediate and batch validation should be 
provided by the fi-amewoik. 65 

Hierefore, for each user interface in an application, 
encapsulate their validation logic in a User Interface Vali- 
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dator. FIG. 130 illustrates a user interface validator associa- 
tion diagram. A User Interface Validator 13000 associates 
various validation rules with the user interface widget they 
are to be applied to. 

The associations are created at the time the user interface 
is created. The validations are triggered when deemed 
necessary by the user interface. Any validations that fail are 
displayed to the user including the type of validation that 
failed and the widget that it failed oa 

The rules are implemented by a different class for each 
type of validation. Each of these validation rule classes must 
know how to check its rule for every type of widget that can 
be checked. As mentioned in the Context section of this 
pattern, this will most likely be limited to text entry type 
widgets. In addition, each validation rule class extends an 
abstract validation rule class that defines what types of 
widgets are supported. This is an implementation of the 
Visitor pattern. 

FIG. 131 illustrates a validation rule class diagram. 

Note that the check operations accept a Validate 13200 
type of class. Each widget that can be validated with this 
framework must implement a vahdateRule method. This 
simple method accepts some ValidationRtile 13202 as a 
parameter and simply turns around and calls the check 
method on the rule passing itself in as a parameter. This 
interaction is shown in FIG. 132, which illustrates a rule 
validation interaction diagram. 

The concrete implementation of the check method will be 
invoked. This method knows how to extract the data from 
the particular widget provided and verify the rule. 

lie User Interface Validator's job is to associate these 
rule instances with all of the widgets they pertain to. When 
the validate method is invoked on the Validator, all of the 
rules are sent to eadi of the appropriate widgets via the 
validateRule method. 

New rules can be added by creating new classes that 
extend off of the abstract Validation Rule class. No changes 
need to be made to the widgets. 
Benefits 

Consistency. All user interface validation rule checking is 

done in the same way using the same rule logic. 
Extensibility. New rules can be added without affecting 

any other part of the application. 
Automation. Application of validation rules can be auto- 
mated with a GUI based tool rather easily. 
The associations between a widget and the rule to apply 
to it should be set up when the user interface is created. A 
user interface can implement a method that accepts a rule 
and widget and passes it on to the User Interface Validator 
as shown in the code example below: 
ValidateTextField userNameField-new TextField("user 
name'O; 

ValidateTextField passwordField-new TextField 
("password"); 

ValidateTcxtArea comraentsArea-new TcxlArea 
("comments); 

this, add Vali da tion(userNa me Field, new 

NotEmptyValidationRule( )); 
this. addValidation(passwordField, new 

NolEmptyValidationRuIe( )); 
this. addValidation(passwordField, new 

NotNumericValidationRule( )); 
this.addValidation(commentsArea, new 

MaxLeogthValidationRule(255)); 
Hie addValidatioQ method on the user interface is shown 
below. 
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public void addValidatiaii(ValidateWidget aWidget, Vali- 
dationRulc aRule) 



UIMtlidator myV^idator - this.get\^idator( ); 
My Validatot addAvlidation(a>A^idget, aRiUe); 



The addValidation method on the User Interface Validator 
is shown below. 



public void addVaUdationCValidateWidget aWidget, ValidatiottRule 

aRulc) 

{ 

HaaKtable rulesAndWidgeta - this.getRulesAndWidgets( ); 
if (rulesAndWidgcts.coiitainsKey(aRule)) 



10 



15 



} 



{ 

}' 

rulesAndWidgets.put(aRuie, aWdget); 



aRulc a aRule.clonc( ); 



20 



In the above code, three widgets are created and then 
associated with various validation rules. The user name and 
password fields are reqiiired and cannot be Left blank, the 
password may not contain any numbers, and the comments 
text area may not be longer than 255 characters. 

Note that each of the widgets is created with a string that 
describes a name for the widget that the user would recog- 
nize. This name is used in the error list to help a user identify 
which widget failed validation. 

At some appropriate time, the user interface sends the 
validate message to the User Interface Validator. This 
method steps through each of the rules provided to it when 
the user interface initialized and passes them to their asso- 
ciated widget by the validateRule method. The code is 
shown below: 



public Vectoi validate( ) 



{ 



Vector errors = new Vectoi( ); 

Hashtable mlesAndWidgete - thi8.getRuleaAndWidgets( ); 
Eniimeiation rules » rulesAiidV^dgcts.keys( ); 
while (rules.IiasMoreElements( )) 

\^HdatioiiRule aRulc - (VklidatioDRule)rules.nextElement( ); 
\Widate\Vidget aWidget - O^lidateWidget) 

RnlcsAndWidgct5.gct(aRulc); 
String anEiror » aWidgetvalidateRulc(aRule); 
if (anError !• null) 



{ 



erro rs .addElcincnt(anEnor) ; 



} 



} 

return errors; 



Note that in the code example above, the validateRule 
message returns a String rather than a boolean. This string 
can be passed back to the user interface that invoked the 
validate and used to describe the errors that occurred to the 
user. 

Collaborations 

Msitor Each of the rules are implemented as a Visitor 
according to the GoF pattern of the same name. 
View Configurer 

FIG. 133 illustrates a flowchart for a method 13300 for 
assigning a view to an activity. Notification is received that 
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a startup event of an activity has occurred in operation 
13302. A reference to a first instance of an object created by 
the startup event of the activity is also received in operation 
13304. In operation 13306, a view to launch is determined 
in response to the receipt of the notification and the refer- 
ence. The view is based on predetermined criteria. The view 
is associated with the activity and displayed in operations 
13308 and 13310. 

The predetermined criteria may include user preferences, 
an experience level of a user, security profiles, and/or 
workflow settings. Also, the activity may be allowed to run 
without a corresponding view. The activity may also operate 
on a machine separate firom a machine of an end user. 

As an option, a request may be sent to be notified when 
a new instance of an object is created. As another option, a 
configuration file may be read for obtaining configuration 
information. 

How do I associate a new view with the appropriate 
business activity underneath, in a configurable manner? 

Consider a user interface that displays and coUects data 
for an activity object underneath. 

The ICM/MVC patterns provide for a layered architec- 
ture. Each layer talks to a layer below it, and no lower layer 
talks to an upper layer. For example, the view messages 
downward to the activity and the business objects, and the 
activity messages to the business objects. Layers talk down. 
No layer messages back upward. 

Traditionafly, activities launch their views direcdy. In the 
example illustrated below, the Search \^ew tells the Search 
Activity to launch the Customer Maintenance Activity, 
which then opens up its own view. But this violates the ICM 
approach, because then the model is talking directly up to 
the view. 

FIG. 134 illustrates a marmer in which the maintain 
customer activity operation 13400 of the present invention 
launches its view 13402. 

It might be more appropriate to let the view layer, rather 
than the activity layer, make decisions about launching other 
views. The view layer already knows about usability 
preferences, positioning on the screen, etc. However, one 
wants the activities to control conversational flow for 
preconditions, postconditions, workflow, and any other addi- 
tional business logic. 

A view should not be able to launch a new, separate 
activity, because that involves business logic. Instead, one 
wants activities to launch other activities. When the activity 
layer controls conversational flow, one needs a mechanism 
to launch views on top of these activities, without violating 
ICM. 

Therefore, a View Configurer 13500 wiU be created to 
manage the relationship between activities 1350(2,13504 and 
views. This would likely be a singleton, 

FIG. 135 illustrates the view configurer 13500 launching 
the maintain customer view operation. 
The View Configurer is a generic mechanism which 
55 allows launching of different views, based on certain crite- 
ria. It uses an observable relationship with activity factories 
to solve this problem. With the View Configurer, developers 
do not hard code the particular policies for the selection of 
a view. Moreover, this mechanism allows activities to run 
60 without a corresponding view. 

Communication from the activity to the View Configurer 
will be conducted through broadcasting (as described in the 
Observer pattern). In this manner, the activity doesn*t know 
about the existence of the View Configurer, it listens to 
activity broadcasts such as when the controUer starts up. 
This configurer can use the Observable Factory to get a 
handle to the activity instance. 



65 
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There are four main steps involved with the View Con- Operating System Services 

figurer observei/observablc interface: Runtime Services 

Prior to the flow depicted above, the View Configurer has Version Management 

registered with the Activity Factory saying "Tell me when a Licensing Services 

new instance is created". TTiis is an ex^ple of an "Observ- 5 Error Handling/Logging Services 

able Factory, which can be thought of as a Factory which ^ « 

properties 

implements the subject/observable role of the Observer f 

pattem. The Factory needs to be a singleton, so the View ^ask and Memory Management 

Configurer has visibility to it. Security 

The Search View tells the Search Activity to launch the "Miscellaneous services' should not be mtcrpreted as 

Maintain Customer Activity. "^^ss important services." In fact, they are vitally important. 

The factory for the Maintain Customer Activity creates a Developers are more productive when they are not required 

new instance of the Maintain Customer Activity. ^0 be concerned over logging and auditing, error handfing 

Because the View Configurer has pre-registered an inter- context issues. Obtaining the freedom to largely ignore 

est in the startup of activities, it will receive a broadcast these issues requires close attention to providing facilities 

message. In this step, the View Configurer should receive a ^^^^^ "^^^ "^^^^ apphcaUon 

• • r i structure, 

mimmum of two parameters: ,^ . j c • . % 

• . ^ . * 1. • * J Despite the pervasive demands of environmental 

Notification of the startup event that has just occurred. -j *- c c a 11 

. ^ _ , . t considerations, many forms of documentation largely gloss 

Areference to the new instance of the object that was just ^^^^ ^^^^^ p^^^ example, many times when reading 

created. ..... 20 API documentation we find authors disclaim the fact that no 

The ^^ew Configurer then detennmes which view to ^^^^ ^^^^ "programming by contract" is shown 
launch, ms can be based on a variety of critena such as ^^^^ examples to improve readabiKty. Yet, getting 
user preferences, e^enence level security profiles, or ^^^^ right is key to stabiUty in the execution 
workflow settings. Hie configurer detennmes the correct environment. Programming by contract with the use of 
view and attaches It to the activity underneath. ^ preconditions and post-condiUons is perhaps the most 
Benefits aggressive style of programming known to date to assure 
Development Depending on the distribution model m ^^^^^^ programs. Assertion, Exception Hierarchies, Excep- 
place, busmcss processmg can be executed and tested ^ion Response Table and Polymorphic Exception Handler 
before the appropriate views have been implemented. ^j^^kle these problems vigorously by helping to define clearly 
Automated testing. The View Configurer is particularly 30 how to solve some of these key kernel application architec- 
useful when you want to use scripts and avoid bringing ture considerations. Hie Exception patterns provide a blue- 
up windows with automated testing. This is especially print illustrating how architectural issues can be abstracted 
true for performance testing, where you might want to into a service level component so that the impact to the 
run 100 transactions, which might involve instantiating application code is minimal. 

100 instances of the same activity. 35 a demanding issue in distributed systems is gathering and 

Running processes in batch mode. The View Configurer using trusted information about the clients interacting with 

aUows processes to run without a View, and makes it the systems. In earlier generations of systems the number of 

very simple to connect, disconnect, or reconnect related users was a faidy precise calculation — just count the number 

views. of workstations v^ch could potentially connect to an appli- 

Distribution Transparency. In a distributed environment, 40 cation. Information about the users was also a fairly simple 

the process might live on a different machine from the matter since they connected directly to the resources from 

end user's machine. In that case, it cannot launch the which they were requesting services. Today, with clients 

view directly, within its own executable. (Unless using offering web services within n- tiered architectures this is no 

a remote windowing system like X-windows, etc.) So longer easUy predictable. In addition, requirements to sup- 

the View Configurer allows application architects to 45 port these less predictable niimbers of iisers and to have a 

transparently move process logic around, depending on personal "one-to-one" relationship with them is key to many 

the distribution model. web strategies. The LoadBalancer and UserContext pattem 

CoUaborations offer some help in this area. The former addresses strategies 

The Observer Pattem (Gang of Four Pattem) describes for ensuring maximal leverage of the system resources and 

how to provide visibility to other entities via a one to many 50 services and the latter helps in addressing the issue of 

relationship. A singleton activity factory will create new maintaining state and context about the user. These facilities 

activity instances, and broadcast the startup of the new are mandatory when security, auditing and logging are 

activities to the View Configurer. considered essential properties of the environment. 

An interface for the creation of activities is used in Assertion 

conjunction with the Observer Pattern. In this way, the 55 FIG. 136 illustrates a flowchart for a method 13600 for 

startup of new activity instances can be broadcast to the testing successfulness of an operation having pre-conditions 

View Configurer. This is described in the Factory Pattem and post-conditions that must be satisfied for the operation 

(Gang of Four Pattern). to be successful. A first assertion is raised in operation 13602 

Generally, there will only need to be one View Configurer asserting a pre-condition that must evaluate to true if the 

per executable. The View Configurer would likely be a 60 operation is successful. The operation is then executed in 

singleton, as described in the Singleton Pattern (Gang of operation 13604. A second assertion is raised in operation 

Four Pattern). 13606 asserting a post-condition that must evaluate to true 

Environment Services (1016) if the operation is successful. An error message is outputted 

Environment Services provide miscellaneous application upon failure of at least one of the assertions in operation 

and system level services that do not deal directly with 65 13608. 

managing the user-interface, communicating with other Optionally, an error handler may be provided for detecting 

programs, or accessing data. These services are divided into: a failure of the assertion of one of the conditions and 
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shutting down a system ninDing the operation upon the 
detection of the failure. As another option, an assertion may 
be raised at the beginning and end of every operation of a 
plurality of operations. Also, a check may be performed 
prior to raising the assertions for determining the propriety 
of raising the assertions. 

Each assertion may be raised with descriptions for helping 
to identify where the assertion failed. Also, each assertion 
may be raised with parameters for helping to identify why 
the assertion failed. In one embodiment, two types of 
assertion classes may be provided. In such an embodiment, 
one of the assertion classes may implement assertion- 
cheddng logic and the other assertion class may implement 
only null operations, with one of the assertion classes being 
selected to be raised. 

Every operation has a set of preconditions and postcon- 
ditions that must be met for the operation to be considered 
successful. If these expectations are not met, the system state 
is in error. How can operations check for these errors so that 
the handling of these critical errors are consistent across the 
application? 

Methods typically obtain and return a value, set an 
attribute based on a passed in parameter, or modify the state 
of the application based on some complex business rule or 
ruleset. While there is always some expected result of the 
invocation of an operation, there are also other, less expected 
possibilities. The provided parameters may not be within the 
expected range, thereby causing an error. A communications 
failure could cause the operation to fail to complete or, 
worse yet, return incorrect data or leave the system in an 
inconsistent state. 

Any complete design determines that some formal speci- 
fication is required to ensure operations complete correctly. 
This specification is most often in the form or pre- and 
post-conditions. These conditions define a set of logical 
expressions that must hold true for the operation to begin 
and eud as expected. These conditions are usually defined 
during the Design Phase of development. An example is 
shown in the Operation Diagram below: 

FIG. 137 illustrates an operation diagram depicting an 
example of pre-conditions 13700 and post-conditions 
13702. 

The conditions, in short, define the contract for the 
method. All of these pre-conditions must hold true before an 
operation's execution and all of the post-conditions must 
hold true after an operation's execution. Only then is the 
operation said to be successful. If any of these conditions 
fail, a critical error has occurred. The system must assume 
it is in an inconsistent state and cannot continue processing. 

It is expected that the system programmers will check for 
pre- and post-conditions systematically in the operations 
they are coding. This seemingly simple requirement 
becomes non-trivial when some issues are considered: 

How can multiple developers implement these checks in 
a consistent manner? 

Some condition checks may be expensive to complete 
(database and remote component queries). How can these be 
turned on and off to meet performance expectations? Prob- 
lem with deferred evahiation; see below. 

How can the exceptions raised when a condition check 
fails be handled in a consistent manner throughout the 
system? 

Therefore, a type of object should be developed to rep- 
resent a check against an operation's conditions. This 
generic class of objects is known as an Assertion. Applica- 
tion developers should then raise Assertions throughout the 
system to check the correctness of the code and system state. 
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An Assertion accepts conditions that must always evalu- 
ate to true. If any of these conditions ever fail, a critical error 
has occurred and the system should shut down. Pre- 
conditions and post-conditions are good examples of the 

5 type of conditions that should be asserted during an opera- 
tion's execution. 

The Assertion class is passed a condition that, if evaluated 
to be false, raises the appropriate errors and shuts the system 
down. The purpose of this pattern is to formally recognize 

10 the pre- and post-conditions of a method in the actual code 
rather than through developer comments. By implementing 
an assert( ) method on a common superclass, the interaction 
with the Assertion class can be hidden from the functional 
developer. An example of the use of assertions is shown 

15 below: 



public Customer cieatcCu8toiner(int newCustomcrNumber) 

^ Customer newCustamer - null; // dedare the new customer 
this.assert(aewldentifler > oyj/ pre-oonditioa^ a customer's 

// identifier must be greater than 
// zero 

// code to create the customer 

this.assert(aewQistomer !- null); // post-conditioa^ the customer 

25 was 

// created 

retura newCustomer; 

} 



30 Assertions can be raised with descriptions and param- 
eters. A description can help to identify where the Assertion 
failed and a parameter list can help to identify why the 
Assertion failed. 

Assertions should be raised at the beginning and end of 

35 every operation. Prior to raising the Assertion, a chedc 
should be made to see if it appropriate to raise one (if 
assertions are enabled, if performance sensitive assertions 
are enabled). This can be accomplished by querying the 
Assertion class for its state before checking the assertion: 

40 



if (1 Assertion. isPcrfctmanceSen8itive( )) 
{ 

// assert! 

45 } 

All operations will have both pre- and post-conditions. 
Even in cases where an operation defines an input parameter 

5Q as something as broad as an integer, it is doubtful that all 
integers are acceptable to the operation. In this case, an 
Assertion should be raised to check if the parameter is in the 
appropriate range. 
A "top-lever* error handler should be defined to catch all 

55 AssertionExceptions and handle them in a clean and con- 
sistent manner. This should include reporting the assertion 
failure and shutting down the system following an orderly 
procedure. 

It is important to note the difference between assertions 
60 and standard error-handling. Assertions are condition checks 
that can be turned on and off during runtime whereas 
standard error handling is always enabled. This is because 
assertions must always be true. The burden is on the testing 
process to catch all failed assertions. Thus, a failed assertion 
65 should simply never happen in deployed code. However, 
exceptions can happen, and therefore cannot simply be 
turned off. 
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Beoefits mined intervals for determining whether a predetermined 

Ease of Error Identification. Many enor are caused by amountof time has passed since each of the objects has been 

invoking an operation with improper data (parameters). accessed in operation 13810. Contexts that have not been 

By formaUzing these conditions, it is very obvious is an accessed in the predetermined amount of time are selected in 

error was caused by bad data or bad code. 5 operation 13812 and information is sent to the clients 

^ ^ T> 1 1 -a ^^^^4- „ ♦k^ identifying the contexts that have not been accessed in the 

Correctness. Properly placed assertions assure that the . / • j . r • .-^-tenA 

^ J „ u i i^A pnedetermmed amount of time m operation 13sl4. 

system IS m a conect state and responses can be trusted. ^ .j., i . j . c r 

Assertion checking complement^ but does not replace, "^^"^ " prese ectcd amount of time for reccmng 

a comprehensive testini program. The responsibility ^Tf"' I ' may option- 

■ „u J * 'A ^« 10 ally be deleted if a response from one of the chcnts is not 

remains with the designer to identify the correct con- • j .l * • j * ai 

ditions to assert received withm the predetermined amount of time. Also, a 

response may optionally be received from one of the clients 

Consistency. All checks wiU be made and handled m a requesting that one of the contexts be maintained. In such a 

similar fashion. situation, upon receipt of the response, a time the context 

Control. The enabling and disabling features of the Asser- 15 was last updated may be updated to a current time, 

tion allows an operations controller to determine when As a further option, a queuing delay may be accommo- 

and what checks should be made at runtime rather then dated for a response from the clients. Also, each of the 

development time. clients may maintain a collection of all objects the client is 

Flexibility. All handling and clean-up of inconect asser- interested in. The clients then may send requests to keep 

tions is located in one place making changes to this 20 alive any objects the clients are currently interested in. 

logic much easier to implement A client requests a server process but due to abnormal 

Readabflity. Polices concerning how assertions are actu- circumstances fails to cleanup. Howis the orphaned process 

ally thrown and handled is not in the functional code. detected and removed? 

Documentation. The code actually documents the design ^ , In the de^gn of a statefiU server the LUW 

assumptions. TOs can also be used by documentation ^ f J^^^ constructmg domain objects at 

generators which read through the code. the request of the clien^ and mamtammg these objects 

Ibe Assertion class can be defined as shown in the ^ given context. Domain objects are entered into a 

folio ' s ecification- registry with their appropnate context which the server 

° maintains and updates when a request is received to create 

uass Assertion ..... , . ^ 30 or delete an object. Each time a context is accessed then a 

void raise(boolean condiUon) throws AssertionExcep- notification is broadcast to the registry, regardless of a state 

. V. , . ^ . , • . X change. With a simple context management, each time a 

void raise(boolean condiUon, Strmg description) ^^^^^ ^ referenced by a cUent a reference counter is 

throws incremented and similarly decrements when the reference is 

AssertionException 35 destroyed. Once the reference count returns to 0 then the 

void raise(boolean condition, Vector parameters) context can be removed from the registry. 

throws jf tjje context is not explicitly deleted by the client then it 

AssertionException will remain in the registry as the server has no way of 

void raisc(boolean condition. Vector parameters, String detecting that the context is orphaned. 

description) throws AssertionException 40 Even if the client application is rigorously designed to 

boolean isEnabled( ) ensure all redundant contexts are deleted, an abnormal client 

boolean isPerformanceSensitiveEnabled( ) event may result in its termination leaving an orphaned 

Qass AssertionException extends Exception server context. 

One possibility on how to handle the enabling and dis- FIG. 139 illustrates a Client 1 13900 that has instantiated 

abling of assertion checking would be to have two possible 45 A 13902 and C 13904, deletes C but fails to delete A. 

types of Assertion class. One which implements the actual The server still has a reference coimter greater than 1 even 

assertion-checking logic and another which only imple- though the client is no longer interested, 

ments no-ops. The Assertion instance is then obtains through Therefore, Distributed Garbage Collection should be 

an AssertionFactory which can be set as to which of the two implemented to ensure that orphaned server contexts are 

types to distribute. Hiese settings are determined at runtime. 50 deleted on the server. In the registry for the Garbage 

It should also be noted that in Java, the exception that is Collection the server maintains a collection of outstanding 

thrown should be a generic run-time exception that doesn't server objects and for each object a list of its contexts, the 

need to be caught by the method or mentioned in the clients currently interested and the duration since a method 

method^ s throw clause. was invoked upon a given context by a client. Periodically 

Collaborations 55 this list is examined to establish if any of the obj ects have not 

Factory been accessed for some configurable time and are candidates 

Distributed Garbage Collection for reaping. So, for example, a value of 5 minutes could 

FIG. 138 illustrates a flowchart for a method 13800 for serve as a default poll event or keep alive interval. If a 

detecting an orphaned server context A collection of out- candidate for a orphaned server process is identified then the 

standing server objects is maintained and a list of contexts 60 cMents are sent a message, requesting if they are still 

is created for each of the outstanding server objects in interested in the context. This might be performed by 

operations 13802 and 13804. A compilation of clients who publishing an "is anyone interested" message to the regis- 

are interested in each of the outstanding server objects are tered clients to estabUsh if anyone is interested in the object 

added to the list in operadon 13806. Recorded on the list in in its assigned context or by asking the clients explicitly 

operation 13808 is a duration of time since the clients 65 depending on the nature of the architecture, 

invoked a method accessing each of the contexts of the The cUent side also maintains a collection of all of the 

outstanding server objects. Hie list is examined at predeter- objects that it is interested in. When it is queried, it instructs 
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the server to keep alive any objects it has an interest in for be partitioned into classes based on the way exceptions are 

which a query has been received. handled, exceptions associated with different layers of a 

FIG. 140 illustrates a GarbageCollector 14000 requesting system, domains, and/or the source of the exceptions. As a 

for interest in context A 14002. No responses are received ftirther option, a class may be created which represents a 

from any clients so the server assumes it is orphaned and 5 source of the exception and holds an original copy of the 

deletes it. exception for avoiding creation of duplicate exceptions. 

If the period configured for a client to respond expires arbitrary exceptions may each optionally support a 

then the context is deleted. This accounts not only for an ^^^^^ ^^^^^ ^^^y^ ^^^^^^ ^ of arbitrary excep- 

abnormal termination of the cUent but for failure of the client ^^^^ 

application to clean up. However, if a request is received Developing exception handling logic without classifying 

from a client to maintain a context then the time the context organizing exceptions makes the handling logic cum- 

was last accessed is updated to the current time and it bersomc and &a^6 to change. How should exceptions be 

remains in the Garbage Collection registry. structured? 

HG. 141 illustrates a GarbageCollector 14100 requesting traditional way of conveying errors is by passing 

for interest in context B 14102. Qient 2 registers interest so ^5 ^^^^ bailee to caller. This approach is adequate 

the reaper updates the access tmie stamp and maintains B, ^ ^^^^ ^^^^^ ^^^^ general, it is less powerful and more 

Benefits prone than an exception based approach. In the tradi- 

aeanup on the Server. Reduces the amount of redundant tional approach, only minimal information can be passed, 

resources on the server to a minimum. This is espe- such as a failure to locate a configuration file (information on 

cially important if a stateful component is held in a 20 which file has to be provided by some other means). It is also 

transaction by a chent and the architecture prevents very easy, and common, to ignore the return code. Projects 

additional clients from accessing it, e,g, with BEA's which faithfully test every return code end up mixing a high 

percentage of error logic with the primary logic. This 

Performance. Ensures that only the required contexts are increases the complexity, and the development, review, and 

maintained on the server, minimizing the work that the 25 maintenance effort. 

server is required to do, especially during the cleanup Some computer languages (Java, C++) support an error 
process at the end of a LUW. reporting mechanism based on exceptions. In these Ian- 
Centralization. The collector has a central view over aU of guages an exception can be a class type and hold arbitrary 
the contexts that are currently accessed by all of the information, such as the name of the configuration file that 
clients within a given context. This simplifies the 30 was missing. Also, exceptions cannot be as easily ignored as 
persistence of a context at the end of processing. return codes. If the callee raises an exception and the caller 
In order to prevent potential race conditions the client doesn't handle it, the caller's caller is checked to see if it 
must be given sufficient time to respond to the keep alive handles the exception. This continues until the exception is 
message fi-om the server before the context is deleted, handled or the program terminates. Designed properly, the 
Typically the client has a separate Ustener for upward 35 error handling logic will be somewhat separated from the 
messages originating at the server, so queuing is not an issue primary logic and will be less dense than the traditional 
at the client end. However, a server is more likely to queue approach. 

on the receiving end, especially in a systena with high The exception class designer is free to create any interface 

message rates. for the class, and each exception class can have its own 

Unless there is a dedicated listener on the server it must 40 unique interface. The exception handling logic 14300 will 

be configured to accommodate for any queuing delay on know which exception 14302 was raised (via runtime 

receipt of the client response. support) and can make use of the interface particular to the 

Collaborates with given exception. You can think of the exception handling 

Context Pattern Language describes the ardiitecture that logic being a set of "chunks" of logic where each chunk 

is required before the Distributed Garbage Colleaion is 45 handles a specific type of exception. With this in mind, you 

required. can see how having many different exception types will 

Variation of cause the exception handling logic to grow. As a new 

Java Shared Namespaces with distributed garbage collec- exception type is added to the system, a new "chunk" might 

tion. have to be added to the handling logic. This is not good. The 

Objectstore PSE WeakArrays. 50 code is not flexible to change and is in several places. Note 

Exception Hierarchies FIG. 143. 

FIG. 142 illustrates a flowchart for a method 14200 for Suppose you have all these chunks of handling logic and 

creating a common interface for exception handling. Nam- discover that the logic is pretty much the same. For example, 

ing conventions of exceptions are determined in operation assume yoiu: architecture is layered and you want to treat all 

14202. A prefix and/or a suffix is added to each exception 55 exceptions from the persistence layer the same, such as 

interface name in operation 14204 for indicating that the logging the error and notifying the user. Also assume that the 

exception interface is an exception. In operations 14206 and persistence layer can raise any one of fifty exceptions, and 

14208, where an exception error occurred is indicated and a more are expected to be added in the future. This is fifty 

determination is made as to what caused the exception error. chunks of code that must be present in the exception 

Context is provided as to what was happening when the 60 handlmg logic, and again, this logic may be in several 

exception error occuiied in operation 14210. Streaming of places. Wouldn^t it be nice to write one chunk of handling 

the exception is allowed to a common interface in operation logic and be done with it? 

14212. An error message is outputted indicating that an Let's take another scenario. Suppose you want to prevent 

exception error has occurred in operation 14214. any raised exception from bringing down your system, as 

As an option, a layer and/or domain may be added firom 65 least not without a fight. In some cases the error will be 

which ead] exception originates to eadi of the names of the \mrecoverable and there is not much you can do but release 

exception interfaces. As another option, the exceptions may resources (locks, communication channels, . , . ) and tcrmi- 



06/17/2004, EAST Version: 1.4.1 



us 6,636^ 

261 

aate. What caused the problem is going to be on the tops of 
the minds of the production support people, and yours when 
you get their call (always in the middle of the night). You 
could write the exception handling logic chunks for each 
exception type — remembering that each exception has its 5 
own interface and will require separate logic to handle each 
interface — ^for each exception, but now you have to handle 
all the exceptions in the system. Wouldn't it be nice to write 
one chunk of handling logic and be done with it? 

Therefore, to simplify the error handling logic and be able 
to treat groups of exceptions the same, a few techniques 
should be used to organize and define the exception inter- 
faces. 

Hie first step is to create an exception interface that all 
other interfaces will use or extend. It is not possible to 
provide one here as it greatly depends on the requirements 
at hand. But here are some guidelines: 

Determine the exception naming conventions. Use either 
a prefix or suffix to indicate that the interface is an 
exception. Also consider naming exceptions with the 
layer or domain they originate fitom. For example you ^ 
may have an exertion, CaAddressExcp, which is 
owned by the Customer Acquisition domain. 

Provide a means to determine where the error occurred 
(file, line, client or server, layer, . . . ) so that it can be 
investigated. ^ 

Provide a means to determine what happened (could not 
open file: XYZ). 

Provide context as to what was happening (Saving 
account information). ^ 

Provide a way to stream the exception or stringify it. 

Consider separate production messages versus debug 
messages. 

Don't try to indicate severity. This is determined by the 
context of the caller, not the callee. 35 

The intent is to be able to handle any arbitrary exception 
the same by having a common interface. Take time and get 
this right, to avoid updating several other exceptions later. 

Now that this base exception interface is available, any 
handling logic can treat all exceptions alike; only one chunk 40 
of logic needs to be written. Specific exceptions can still be 
handled on a case by case basis as required. You can extend 
this concept to further partition the exceptions by creating a 
tree of exception types. By handling any exceptions at 
particular point in the tree, you effectively handle all excep- 45 
tioD types below that point. The trick is in creating a useful 
tree. Here are some guidelines: 

Determine where handlers will be put and how they will 
respond to each exception. If you find that many are handled 
in the same way there may be a natural grouping that can be 50 
leveraged. 

Consider the stability of your grouping. Is the group 
cohesive or is regrouping likely? 

If parts of your system are layered, consider a branch that 
consolidates each layer. This enables a handler to deal widi ss 
all exceptions emanating from a given layer. 

Consider grouping by domains (Legal, Finance). 

Consider grouping by subsystem 

Consider common problems such as parameter validation, 
pre- and post-conditions 60 

Consider the source (client or server). 

HG. 144 illustrates that groupings are not always exclu- 
sive. It is possible to group some exceptions 14400, 14402, 
14404 by layer and then domains within that layer. 
Benefits 6S 

Simplicity. Simplifies handling logic by being able to 
write a handler that deals with the base exception type. 
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Consistency. Consistent approach to error handling. 
Maintainability. Minimizes coding changes by reducing 

the multiple number error handling chunks. 
Manageability. Provides Conceptual Framework 
The solution section covered many of the considerations 
in creating the exception tree so this section only provides 
some additional details to consider. 
Wrapping and delegation can be used to simplify in 
certain situations. Consider a distributed apphcatioo 
and the need or desire to handle server and client 
exceptions differently, or to know the source of the 
error. One way to avoid creating duplicate exceptions 
(one per source) is to create a class which represents the 
source and holds the original exception. For example 
AaServerExcp can hold a pointer to the base class 
AaExcp. The handling logic can catch AaServerExcp 
exceptions and then access the held exception. An 
alternative is to put a code in the base class with 
indicates source but then all logic needs to know to set 
this value and all handling logic needs to test for it. 
To hold onto an arbitrary exception you need a way of 
creating a copy of it, but you may not know the actual 
type of the exception. In C++ the exception will be 
destroyed when you leave the handling logic, so you 
need the ability to create a copy to hold onto. A 
common technique is it have all exceptions support a 
"clone" method which creates a copy of themselves. 
Consider how to stream an exception so it can be sent 
from server to chent. 
Exception Response Table 

FIG. 145 illustrates a flowchart for a method 14500 for 
recording exception handling requirements for maintaining 
a consistent error handling approach. An exception response 
table is provided in which an exception is recorded in 
operations 14502 and 14504. The context of the exception is 
entered in the exception response table in operation 14506 
and a response for the exception is listed in the exception 
response table in operation 14508. The response is subse- 
quently outputted upon the exception occurring in the con- 
text in operation 14510. 

A typical response and a last resort response may be listed 
in the exception response table. The typical response may 
also be outputted upon the exception occurring in the 
context. The last resort response may be outputted upon the 
exception occurring out of the context. Additionally, abbre- 
viations may be used to reduce an output size of the 
exception response table. Further, the exception response 
table may also include an exception category field for 
permitting organizing multiple exceptions by source. 
Optionally, an optimization may be determined that can be 
made based on similar entries in the exception response 
table. Further, the optimization made may also include 
classffying the exceptions for organizational purposes. 

The response to an exception may vary per exception type 
and the context in which it is thrown, such as being thrown 
on the client or server, and the context in which it is handled. 
How do you record the exception handling requirements? 

During exception handling design there are several 
aspects to capture to achieve a consistent approach: 
The set of exceptions to be handled 
The set of responses to these exceptions 
The context in which the exception is handled; e.g. client 

or server, batch or GUI 
The set of exceptions to handle and their organization 
stmcture varies by project. Typically exceptions are orga- 
nized into hierarchies to facilitate handling. The response to 
an exception may vary by exception type, the context in 
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which it was thrown, and the context in which is handled. 
Here arc some examples of error handling decisions of a 
hypothetical project: 
"All exceptions thrown on the server, and not handled by 

the server logic, will be propagated to the client." 5 
"The current transaction is aborted if a server exception is 

not recoverable" 
"All Server exceptions derived from Excp will be logged 
if not handled by the server code. The last resort 
handler will ensure this." jo 
"GUI chents will display the error information in a spHtter 
window** 

"Batch clients will send error information to Operations" 
These few examples demonstrate how context (Batch, 
GUI, Client, Server, last resort) can affect the hantuing of -^5 
exceptions, and that even in a given context, the exception 
type may play a role in the handling. In a real system there 
may be several other context and exception-type specific 
requirements. 

There are two common exception handling contexts that 
should be present in most systems. One is referred to as the 20 
Typical Response and the other is referred to as the Last 
Resort Response. The T5rpical Response is the error handUng 
code intentionally added to handle exceptions. For example, 
car.start( ) is likely to fail due to being out of gas. The 
Typical Response may be to fill the tank and retry. The Last ^ 
Resort Response is what to do when an exception is not 
handled (the Typical Response could not handle the error, 
such as a hole in the gas tank). Last Resort Response is a 
way of capturing what should be done when application 
code fails to handle an error. Recovery is usually not 
possible at this point but the handler may be coded to log the 30 
error and notify Operations of the problem. Without this 
response, systems may crash unnecessarily, or without indi- 
cating what happened. 

All these permutations of exception types, contexts, and 
responses need to be managed in order to maintain a 35 
consistent error handling approach. 

Therefore, use an Exception Response Table to capture 
the exceptions in the system, and the appropriate responses 
by context. What is important to capture is the exception, 
context, response, information; documenting the error han- 4Q 
dling requirements. 

The following table lists exceptions by category and type, 
with the typical and last resort response. Other contexts and 
responses are listed within these columns. The exception 
category field is optional but can help to organize exceptions 
by their source (application, architecture, . . . ) or hierarchy. 
This table can become qxiite packed with response informa- 
tion so a nomenclature may need to be developed to con- 
dense the information. The implementation section provides 
an example of this; Other ways of formatting this informa- 
tion are possible. 50 



Exception 



Topical 
Response 



Last Resort 



55 



Exception Category 

Exception-Name 
DescriptiDa 

Exception Category 

Exception-Name 
Dcscr^tion 



Benefits 65 
Requirements Traceability. Exceptions requirements are 
captured and managed through implementation. 



Hierarchy Design. Analysis may show optimizations that 

can be made such as handling a subtree of exceptions 

with the same code, as the response is the same to any 

exception in the subtree. 
Interface Design. Discovery of interface requirements on 

the exception classes to support a particular response is 

another benefit. 
Handler design. Assists in exception handling design by 

identifying common responses that can be leveraged by 

the handlers. 

The table below shows an example of an Exception 
Response Table for a fictitious cUent/server system. This is 
followed by the nomenclature section which is customized 
per project. 



Name Typical Response Last Resort Response 

Architecture Framework 
Exceptions 



AaAsscrtionExcp 
Assertion Allure 



C N/A 
SiN/A 



AflExcp O. N/A 

Base class for exceptions S: NyA 
implication Exceptions 



C: L, Popup(scvcTc), 

Shutdown 

S: L, N, 

P(AaServcrAaExcp), 
Shutdown 
ON/A 
S: N/A 



CaBalanceExcp C: PopTip(warn) C L, Popup(wartt) 

Account out of balance S: S: L, N, 

P(AaServerAaExcp) P(AaServcrAaExcp) 

Nomenclature: 

Note: Abbreviations were used so that the table could be printed. The 
nomenclature section is only meant to serve as an example. 

Context 

C-Client 

S=Server 
Response 

N/A-not applicable; don't handle 

Lolog error 

L(diagnostic)=log errors for diagnostic purposes only 
N=notify operations 

Optional=apphcatioD, context dependent. Not required to 

be caught 
P-pass exception to client 

P(<exception>)=pass given exception type to client, will 

be different from type caught 
Popup(warn)=display warning message 
Popup(severe)«display severe warning message 
Popup(rctry)«display retry message 
Shutdown=release resources and shutdown gracefully. 
Exception Hierarchy discusses how to organize excep- 
tions. 

Last Resort Exception Handling describes where handlers 
should be placed to prevent a program ftom terminating 
without warning. 

Polymorphic Exception Handler describes how to design 
and code exception handlers that reduce the impact of 
changes and the overall size of the error handling logic. 
Polymorphic Exception Handler 

FIG. 146 illustrates a flowchart for a method 14600 for 
minimizing the amount of changes that need to be made to 
exception handling logic when new exceptions are added. 
Exceptions are organized into hierarchies in a polymorphic 
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exception handler in operation 14602. A root of one of the 
hierarchies in which an exception occurs is caught in opera- 
tion 14604. The exception is instructed to rethrow itself in 
operation 14606. The rethrown exception is caught and 
identified in operations 14608 and 14610. A type of the 
rethrown exception is determined in operation 14612 and a 
message is outputted indicating the type of the rethrown 
exception in operation 14614. 

Single exception interfaces may be used as the roots of the 
hierarchies. Also, the polymorphic exception handler may 
handle each unique root. Further, an added exception may be 
organized into a hierarchy and handled by the polymorphic 
exception handler. As an option, handling behavior may be 
encapsidated in the polymorphic exception handler. As 
additional option, catch blocks may also be created to catch 
the rethrown exception. 

Large systems can be quite complex and require error 
management integrating disparate components and/or librar- 
ies (i.e. DBMS APIs, data structures library, middleware, 
etc) How can exception handling logic be written so that 
httle or no cbanges are required when new exceptions are 
added to the system? 

A software system using exceptions as the error handling 
approach may have to respond to a variety of exceptions. 
Handling each exception type on a case by case basis is 
cumbersome and expensive, both in terms of initial devel- 
opment and subsequent maintenance. In languages such as 
Java and C++, the mechanism to handle exceptions is to use 
try-catch blocks which look like this: 



try 

{ 

// pexfonn some work here 

} 

catch (E)tceptionTypeA& «cp) 
{ 

// Exception A throwii.Handliiig logic here 

} 

catch (ExceptionTypeBft excp) 

// Exception B thrown. Handling logic here 

catch (...) 
{ 

// Don't know what was thrown, but still need to handle it. 

} 



This example shows only two explicit exception types 
being handled but a system typically has several potential 
exceptions. If the development of the exception types is 
poorly designed the tiy-catch blocks can become quite large 
as they attempt to handle each exception. Imagine trying to 
handle, say, fifty more exception types, in several places, in 
the code. The error handling code expansion is exponential! 
FIG. 147 depicts a program 14700 (i.e., the exception 
handler of the present invention) with a few try-catch blocks 
14702. As more exceptions are added these blocks expand to 
handle each new exception. 

Another problem with exception handling logic is that it 
can be quite involved, such as logging the information to a 
persistent store, notifying Operations support, rolling back a 
transaction, etc. the example only showed one commented 
Une to represent the code. Again, imagine each catch block 
requiring several lines of code. This logic may be repeated 
in each catch block. 

Taken together, varying exception types and potentially 
repealing and complex logic in the catch blocks, the devel- 
opment and maintenance efforts regarding enor handling are 
going to be much more expensive than they need to be. 



10 



15 



20 



25 



30 



Therefore, structure the exceptions into hierarchies, create 
an exception handler object that performs the catch block 
logic, and minimize the number of catch blocks required to 
support a given try-block 

Exception Hierarchies organizes exceptions into hierar- 
chies and fadUtates the design of exception handlers. Han- 
dlers can then be designed to handle the roots of hierarchies. 
This is much simpler than handling each exception type on 
a case by case basis. In custom development where the 
project has control of all code, a single exception interface 
can be used as the root. The more likely situation is some 
custom development and using third party libraries which 
may also use exceptions. In these cases, the exception 
handler will handle each unique root. 

Using an exception handler, versus custom logic per catch 
block, reduces the maintenance and development effort as 
the code is easier to read, there is less of it, and any changes 
that need to be made can be made in one place. 

Hie following code snippet shows the form of the try- 
catch blocks using the polymorphic exception handler. It 
may seem equivalent to the prior catch-block example but it 
is not. The first distinction is the type of exceptions handled. 
In this case, the roots of the exception hierarchies are caught, 
not the individual exception types. For this example there 
are only two exception hierarchies in the system, so only 
these roots are handled. What this means is that as new 
exceptions are added to the hierarchies, this code does not 
change, and remember, this code is in several places in the 
system. 

The second difference with this code is the encapsulation 
of the handling behavior in the exception handler. The 
handle method can perform arbitrarily complex logic behind 
the scenes, and if this needs to change, is changed in one 
place. For example, if the cunent handling logic logs a 
message to disk and now needs to be extended to notify 
Operations personnel, this can be centralized in on place. 
The code as written does not need to change. 



40 
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}{ peifonn some work here 

catch (EzceptionRcot& exap) 

ExcpHdlr hdJr, 
hdlt hand]e(excp) ; 

catch CniirdPortyRoot& excp) 

ExcpHdlr hdlr; 
hdlr.handlc(excp); 

catch (...) 

ExcpHdlr hdlr; 
hdliihandle( ); 

} 



FIG. 148 depicts the same program 14800 (the poljonor- 
phic exception handler) with smaller catch blocks 14802. A 
handler 14802 has been added which is consolidates the 

60 common code and the number of catch blocks has been 
reduced overall by makiiig the handler responsible for 
handling each exception. The downside is that now the 
handler is subject to frequent change as exceptions are added 
to the system. The maintenance effort outweighs this disad- 

65 vantage. 

The examples have shown a single exception handler 
being used. In practice it is more likely that multiple will be 
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used. For example, the exception handler on a server may 
have different requirements or constraints than a client, or 
one client may be GUI based and display pop-up error 
messages, where another client is a batch program that needs 
to send notification messages to Operations. This can be 
handled by creating multiple handlers or using the Strategy 
pattern to customize the behavior. 
Benefits 

Simplicity. Reduces development and maintenance effort 

required for exception handling 
Maintainability. Reduces impact of changes 
Robustness. CentraUzes/Eocapsulates handling logic 
Flexibility. Multiple handlers can be used 
The exception base class declares a method, rethrow, 
which is used by the handler to determine the real type of the 
exception. Another approach is to use double dispatch which 
may be show in a future version. Below is an example of this 
interface only showing the essential detail. 



//- Base Class of Exceptions 
dass Excp 

i 

public: 

//- Rethrow the exception. Throw •this; 
virtual void rcthrow( ) const - 0; 

); 

//- Example Derived Class of Exceptions 
// 

class Derived : public Excp 

{ 

public: 

virtual void rethrow ( ) const { throw "this; } 

}; 

// 

//- Example Derived Class of Exceptions 

class SubDerived : public Derived 
{ 

public: 

virtual void retlirow( ) const { throw •this; } 

}; 



When the exception handler is passed the exception fiom 
the catch-block all it knows it that it has a root exception 
type. For some projects this may be sufficient if the excep- 
tion interface is rich enough and all exceptions are treated 
the same. In other cases, exceptions may require specialized 
treatment With the rethrow mechanism in place, the handler 
can create a try-catch block and have the exception rethrow 
itself. The catch blocks are then used to catch the specific 
exception type. 



ff. 

//- Exception Handler 

class ExceptionHandler 

public: 

ExceptionHandler( ); 

//- E^ndle the root exception 

void handIe(const Exqp& ); 

//- Elandle a third party root 

void handlc(const 'niirdPaityexq]& ); 

}; 

//- Handle the excq)tion 
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-continued 

^ void ExceptionHandler::handJe(const Excp& e) 

//- Rethrow the exception to get the qjccific type 

//- Note that catches are in the order of most specific to 

//- most general. 

try 
{ 

10 e,rethiDw( ); 
} 

catch(SubDerivcd& txcp) 
{ 

// Handle SubDerived 

} 

J 5 catcb(Derived& excp) 
// Handle Derived 

} 

catch(...) 
{ 

// Handle e parameter here since nothing matched it. 
20 J 

} 

ExccptionHBndler::handle(const 'niirdFartyExcp& e) 

{ 

// &ndle based on ThirdPartyExcp interface 
// Can't rethrow because ThirdPartyExcp doesn't support this. 
25 // Could use KITl if needed. 
} 



Load Balancer 

FIG. 149 illustrates a flowchart for a method 14900 for 
distributing incoming requests amongst server components 
for optimizing usage of resources. Incoming requests are 
received and stored in operations 14902 and 14904. An 
availability of server components is determined and a listing 
of available server components is compiled in operations 

35 14906 and 14908. A determination is made as to which 
server component on the listing of available server compo- 
nents is most appropriate to receive a particular request in 
operation 14910. Each particular request is sent to the 
selected server component determined to be most appropri- 

40 ate to receive the particular request in operation 14912. 
Optionally, the determination of which server component 
is the most appropriate may be performed by allocating the 
requests on a round-robin basis whereby requests are 
assigned to consecutive server components by traversing 

45 along the listing of available server components. As another 
option, the determination of which server component is the 
most appropriate may also include calculating an amount of 
utilization that each available server component is currenUy 
experiencing. 

50 The amount of utilization of each available server com- 
ponents may be calculated based on current CPU utilization, 
kernel scheduling run-queue length, current network traffic 
at a node to the server component, and/or a n\maber of 
requests currently being serviced. Also, a request may be 

55 rerouted to a different available server component upon a 
crash of the selected server component. Additionally, the 
server components may be saved in a persistent store, 
wherein a check is made to determine whether a connection 
to a server component needs to be reestablished. 

60 In order to support scalability in a high volume distributed 
component environment, resources tend to be replicated. 
How can incoming requests be distributed amongst the 
available server components in order to optimize the usage 
of system resources? 

65 In a distributed system, server components provide func- 
tions and data that can be accessed by client components. 
Many identical copies of a server component can be nmning 
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on different platforms in the system in order to support large roles in operation 15206. In operation 15208, a user context 

volumes of client requests. instance is created upon successful identification of the user. 

In order to make use of the system's scarce resources. The user context instance also includes information about 

some way of routing an incoming request to the best server the user including the roles. A request is received from the 

component available is required. In general, all requests take 5 invoke a service on a component in operation 15210. 

a similar length of time to service. component invokes an additional service of another 

FIG. 150 illustrates server components 15000 receiving component The user context is queried for the information 

service requests 15002 about the iiser in operation 15212. The user information is 

Ihereforc, use Load Balancer to select the best server comPffed with an access control list for verifying that the 

component out of an available pool for the cUent to use. lo .^^ ^^.^ ^? <^°°ipo^^^ m operation 15214 The 

r-T>. 1M -11 * * 1 JU1 leiftA J- *• *t- user mformation IS also compared With an access control list 

^^}^n \^la ^"^^"^ ^^^^^ mediaUng the for verifying that the user has access to the additional service 

requests ot HO. 150. ^ . ^ . of other component in operation 15216. 

Incoming client requests are routed by the Load Balancer OptionaUy, aU user interactions may be logged as well. As 

to the best available server component. another option, a user interface may be modified to provide 

A number of possible strategies exist for deciding which 15 access to actions that can be performed by the user based on 

server component is the most appropriate at a given point in an identity of the user and the roles associated with the user, 

time. The user context instance may also be passed along as a 

Round Robin — Allocate the received requests on a round- parameter of service invocations. Additionally, the service 

robin basis, whereby a list of the available server invoked may associate any objects created, updated, or 

components is created and, as requests are received, 20 deleted with the user context instance. As a further option, 

they are allocated by traversing down the list When the the user context instance may also encapsulate security 

end of the list is reached, the next request is allocated certificates of the user. 

to the server component at the beginning of the list. For security and auditing purposes, user information must 

Utilization Based-Allocate the received requests based maintained throughout a service's implementation across 

on the utiHzation that each server component is cur- ^5 multiple distnbuted platforms. How can this original secu- 

rcnayexperiencing.Thedefinitionof utilizationcanbe profile be maintained throughout nested service invo- 

tailored to meet specific requirements or deployment ^^^^^^f distnbuted components? 

strategies. It may be based on a combination of cuncnt All mission-critical systems require some form of security 

CPU utilization, kernel scheduHng rmi-qucuc length, and auditmg capacities ^lese capabihties r^^^^^^ 

current network traffic at that node, mimber of requests ^ the system and what they can and cannot do and, m the 

currently being serviced, or any other factors particular ^ ^^^^^^^^ ^''^^^^^ °^ ^P^'^' 

to the environment. and when. ...... 

Benefits capabihties, users must be identified, 

„ . « . , , . . , associated with roles and granted authorization before any 

Performance. Based on the selecUon strategy employed, 35 „atio„ proceeds. In addition, all user interactions and 

ttie cbent IS connected to the server component that is ^^^^^ interactions may be logged. On a user 

es a e o serve i interface, access to certain panels and controls are granted 

Scalabihty. As the number of users and requests increase, according to a user's role, 

processing can be distributed across the available In a distributed, component-based system, these complex 

resources. 40 requirements become even more difficult to implement. 

Robustness. In the event of the server crashing, the client Typically, a client (or user) invokes some service on a 

can then ask the Load Balancer to provide another component. That component may invoke any number of 

server component for it to use. This can be extended additional services on any number of additional components 

still further by federating Load Balancers and their to complete its designated task. These successive service 

associated server component pools. 45 invocations are a result of the irutial chent request so the 

The following is the IDL that was used to define the Load security profile that allowed the initial request must also 

Balancer: allow all successive requests. 

FIG. 153 illustrates a component interaction diagram 
showing an interaction between a number of components in 

interface LoadBalanccr ^ financial system. A user initiates an addStock( ) service 00 

^ the Portfolio component 15300. To perform the addStock( ) 

Object getService ( ) Service, the Portfolio must use the getStodcPrice( ) and the 

raises ( ArchitcctureException ); deductFroinAccount( ) services on the Market and Finance 

void register ( in Object aServerComponent ) components 15302,15304, respectively. This implies that a 

raises ( ArcnitecturcEiEccption ); ^ , ' . \ ^ y x . , . 

J. 55 user who can access the addStock( ) service must also have 

permissions to access the getStockPrice( ) and the 

. deductFromAccount( ) services. This may need to be 
CoUaborations checked by each of the distributed components within the 
Round Robin Load Balancing context of one logical service. In addition, auditing what has 
Utilization Based Load Balancing 60 been done, or perhaps requested to be done, adds another 
User Context common requirement that must be accounted for A compo- 
FIG. 152 illustrates a flowchart for a method 15200 for nent servicing multiple clients must associate client requests 
maintaining a security profile throughout nested service with corresponding services invoked on business objects, 
invocations on distributed components, hi operation 15202, This information must be persisted as each change is corn- 
interconnections are provided between distributed compo- 65 mitted. 

nents each having nested service invocations. A user is Therefore, represent information about a user in a shared 

identified in operation 15204. The user is associated with User Context object. This object maintains a user's unique 
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identification that can be subsequently checked against a 
resource's access control list (ACL). A User Context 
instance is created upon a user's successful, validated iden- 
tification to the system (usually through some "login" 
mechanism). After that, the system user interface can modify 
itself to provide only the actions that can be performed by 
that particular \iser acting in a particular role. Controls may 
query the User Context and modify their own visual state as 
needed (enable/disable, hide/show). 

The User Context can also be passed along as a parameter 
of service invocations. All public, stateless services on a 
component should provide for a User Context to be passed 
along as a parameter Hie service being invoked can then 
associate any Business Objects created, updated, or deleted 
as a result of the service invocation with the User Context. 

One example of this would be a User Manager 15400 
associating a User Context instance 15402 with the Business 
Objects 15404 they are affecting, FIG. 154 illustrates a user 
manger/user context relationship diagram. 

Hiese associations can be used for auditing purposes. 
When a change to a Business Object is committed, a log 
entry can be created tying the change with the user that 
triggered it. 
Benefits 

Common User Representation. One single representation 25 
of a user and their access rights can be shared across all 
areas of the system. 

Extensible Security. Because there is one source for the 
User Context various policies or strategies could be 
used to identity and authenticate the User within a 30 
context. For example, it could encapsulate the User's 
certificates that allow more advanced security strate- 
gies to determine authorization. 
Qass UserContext 

UserContext(Identifier identifier) 35 
Identifier getldentifier( ) 
String getName( ) 
void setName(String newName) 
void addRight(String accessarea, AccessLevel level) 
void removeRight(String accessArea, AccessLevel 40 
level) 

Vector gelRights(String accessArea) 
boolean canCreateIn(String accessarea) 
boolean canReadIn(String accessArea) 
boolean canUpdateIn(Striiig accessArea) 45 
boolean canDeleteln(String accessArea) 
Class AccessLevel 
static AccessLevel create( ) 
static AccessLevel read( ) 

static AccessLevel update( ) 50 

static AccessLevel delete( ) 

boolean=(AccessLevel anAccessLevel) 
It is expecteid that the User Context will be passed fiom 
component to component. In this case the User Context will 
have to be defined using some sort of interface language 55 
definition (IDL). 
Collaborations 
Permission 
Policy 

SecurilyManager 60 

Logging 

Alternatives 

MTS & EJB offer an environment that does not require 
the passing of the context with every operation. A container 
as a set<context type> that provides a handle within the 65 
component for the methods to access the cached context. 
Information Services Patterns 



Reliable information access mechanisms in a multi-user 
environment are a crucial, technical issue for almost all 
systems that a user builds. 

Most business information systems manage data which 
must be saved in non-volatile storage (e.g., disk). The data 
must live, or "persist," between invocations of any particular 
application or program. Persistence is the capability to 
permanently store this data in its original or a modified state, 
until the information system purposely deletes it. Relational 
databases, object databases, or even flat files are all 
examples of persistent data stores. 

This section discusses issues and approaches for devel- 
oping an object-oriented persistence architecture. 

A key issue fi:equenlly encountered in the development of 
object-oriented systems is the mapping of objects in memory 
to data structures in persistent storage. When the persistent 
storage is an object-oriented database, this mapping is quite 
straightforward, being largely taken care of by the database 
management system. 

In the more common situation where the persistent stor- 
age is a relational database, there is a fundamental transla- 
tion problem or a so-called "impedance mismatch". The 
physical, logical, and even philosophical differences 
between a relational and object data storage approach are 
significant. Mapping between the two is hard. TTie architec- 
ture must, in this case, include mechanisms to deal with this 
impedance mismatch. 

The impedance mismatch is due to the following con- 
trasting features of objects/classes and tables: 

Identity: Objects have unique identity, regardless of their 
attributes. Tables rely on the notion of primary key to 
distinguish rows. While a relational DBMS guarantees 
uniqueness of rows with respect to primary keys for 
data stored in the database, the same is not true for data 
in memory. 

Inheritance: This is a meaningful and important notion for 
classes; it is not meaningful for tables in traditional 
RDBMSs, 

Navigation: The natural way to access and perform func- 
tions on objects is navigational, i.e., it entails following 
references from objects to other related objects. By 
contrast, relational databases naturally support associa- 
tive access, i.e., queries on row attributes and the use of 
table joins. 

The patterns in this section focus on problems and solu- 
tions associated with using a relational DBMS with an 
object-oriented persistence ardiitecture. 

A key objective of a comprehensive object-to-relational 
persistence architecture is shielding the application business 
logic and developers from the relational structure. The 
benefits are a simplified environment for business 
developers, reduced distraction with technical issues, and 
increased focus on the business object model and functional 
logic. However, in order to reap these benefits, a significant 
investment in architecture development is typically required. 

The scope of a persistence architecture can range across 
the following levels of transparency and automation: 
Heavyweight, fully-automated, including the mapping of 
the object model to the database schema and generation 
of all the database access code. Variants of this archi- 
tecture type may allow the customization of database 
access code (e.g., for optimization purposes). 
Lightweight mechanism which provides generic persis- 
tence capabilities to business objects but delegates all 
database access to separately developed data access 
routines. In this case, the data access routines arc not 
part of the persistence architecture per se. 
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Minimal persistence approach in which each business 
object is directly responsible for database access 

Of course, there is a tradeoff between transparency, 
automation, and flexibility on the one hand, and architecture 
complexity and development cost on the other. 

Hie patterns in this section solve several of the funda- 
mental problems encountered in the development of an 
object-to-relational persistence architecture, including the 
mapping of classes to tables (Data Handler, Individual 
Persistence), identity management (Object Identifiers as 
Object), caching(Object Identity Cache), allocation of 
responsibilities (Data Handler, Piecemeal Retrieval, Persis- 
tent State Separatefirom Persistent Object), and data access 
optimization (Multi-Object Fetch) and the mapping of basic 
SQL types to object attributes (Attribute Converter). 

In addition to providing persistence capabilities, reliable 
information access mechanisms in a multi-user enviroimient 
must support transaction semantics. As the real-life imple- 
mentation of all of the patterns in this section requires 
integration with transaction management frameworks, the 
Persistence patterns should be considered and used in con- 
junction with the patterns in the Transactions section. 
Attribute Converter 

FIG. 155 illustrates a flowchart for a method 15500 for 
translating an object attribute to and from a database value. 
A database is provided and a conversion process is deter- 
mined for converting an object attribute to and from a 
database value in operations 15502 and 15504. The conver- 
sion process is encapsulated in an attribute converter. A first 
object attribute is directed to the attribute converter for 
conversion to a first database value in operation 15506. A 
second database value is directed to the attribute converter 
for conversion to a second object attribute in operation 
15508. 

A different attribute converter may be created for each 
type of conversion of object attributes to and from database 
v^ues. In addition, the attribute converters may also imple- 
ment a common interface. Further, all attributes of the same 
type may be directed to a particular attribute converter 
Optionally, a second attribute converter may be substituted 
for the attribute converter for altering the conversion of the 
attribute. As an another option, the attribute converter may 
be altered for relieving a performance bottleneck. 

Object attributes must go through some translation before 
they are written to and after they are read from some 
persistent stores. How can you isolate the translation algo- 
rithm from the persistent object and the persistence mecha- 
nism? 

When interacting with a relational data store, the attribute 
value doesn't always map directly to a database type. Other 
times, an attribute value maps to more than one database 
type. 

For example, in an Object based system, an attribute with 
a Boolean value is often converted firom a Boolean object to 
a "T" or "P* string before it is saved in the database. In 
another example, a phone number attribute might be com- 
posed of an area code (847), an exdiange (714) and an 
extension (2731). These three field might be saved in three 
separate database columns or combined into one before they 
are saved in the database. 

FIG. 156 illustrates that an attribute 15600 canH be saved 
directly into the persistent store 15602. 

An impedance mismatch exists between the attribute and 
the data store and a conversion must take place. 
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The logic to perform this conversion can vary firom one 
attribute to another. Based upon the attribute type, a different 
conversion must take place. In addition, special situations 
can arise where the same type of attribute will be stored 
5 differently in different situations. It is desirable to reuse this 
logic; however, the solution mxist be flexible enough that the 
developer is not locked into one single translation for an 
attribute type. 

Therefore, use an Attribute Converter to translate data- 
base values to object attributes and vice versa. 

FIG. 157 illustrates the use of an Attribute Converter 
15700 to save an attribute 15702 into a database 15704. 

The knowledge of how to translate an attribute value to 
^5 and from a persistent store is encapsulated in a separate 
Attribute Converter object. 

The attribute's value should not be obtained directly from 
the attribute prior to saving it in the database. Nor should an 
2Q attribute be instantiated directly from the raw value obtained 
from the persistent store. Values should be obtained or 
attributes created exclusively via an Attribute Converter. 

It is recommended that a different Converter be created 
for each type of conversion required. This keeps the Con- 
25 verter's knowledge very specialized. As a result, the com- 
bination of Converters required to persist an entire object to 
a persistent store is very flexible due to the modularity of the 
Attribute Converter objects. 
Benefits 

Reuse. For some types of attributes, the conversion pro- 
cess can be rather involved. If this knowledge is 
encj^sulated in an Attribute Converter, it can be reused 
for converting other attributes of the same type. 
Flexibility. If the conversion for a specific attribute needs 
to be altered, simply substituting a different Attribute 
Converter will alter the behavior and not disrupt the 
rest of the application. 
40 Maintainability. Altering a single Attribute Converter can 
affect several attributes in the system. For instance, if 
the conversion of one specific type of attribute is 
identified as a performance bottleneck, altering the 
corresponding Converter can benefit a large part of the 
45 system. 

Ideally, all Attribute Converters should implement a com- 
mon abstract class or interface. This allows the architecture 
to treat all Converters equally. The architecture need not 
know the specific translator class it is using. 
50 The interface may look something like this. 



public interfece AUributeConvMtei 

public String traii8latc\^lueForDataStorc(Objcct anAttributc); 

public Object translate ValuePramDalaSloreCString aColumn, 
java.8ql.RcsultSct aResultSct); 
} 



60 The first behavior, translate ValueForDataStore, takes an 
attribute and translates it into a String that can be used in an 
SQL statement. The second behavior, 
translate ValueFromDataStore, takes a column name and 
JDBC result set as arguments. It then answers the attribute 

65 translated &om the given result set. Each implementation of 
AttributeConvcrter must then implement both behaviors in 
their own specific way. 
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public dass BodcanTranslator implcmcots AttrflniteOonvcrtcr 



{ 



public String translate ValueForDataStorc(Object anAttribute) 



{ 



String value - null; 
if(anAttributc null) 
{ 

i£(((Booleaii)aiiAttTibute).boolean\%liie( )) 



{ 
} 

else 

{ 



value = "'T'"; 



} 



value = *"F" 



} 



} 

dse 
{ 

} 

letum value; 



value » "NULL"; 



public Object tranjilate'\^lueFromDataSlote(String aColumn, 
java.sqLRcsultSet aRcsultSct) 
{ 

Boolean result - null; 
Strmg value » null; 

value «> aResultSetgetStriiig(aColumn); 

if(value.equalslgnorcCasc('*P*)) 

{ 

result - new Boolean(true); 
else if(value.equalsIgnoreCase(*F')) 
result " new Boolean(false); 

} 



return result; 



Hie Boolean Converter above knows how to translate a 
Boolean object to and from a character representation in the 
relational database. 
Collaborations 

Normalized Mapping — The Mapper contains all informa- 
tion required to store an object in a relational data store. 
Attribute Converter can be utilized by Normalized Mapping 
to store the knowledge needed to properly translate attribute 
state values to and from the persistent store. 

Denormalized Mapping — Denormalized Mapper is 
another pattern for mapping objects to a relational database. 
The Attribute Converter pattern could be used by Denor- 
malized Mapper to provide conversion between attribute 
values and database values. 
Alternatives 

Case Statements — Case statements aren't really a pattern, 
but they are an alternative to Attribute Converter. A case 
statement could be implemented in the super class to handle 
the translation of the data. 
Data Handler 

FIG. 158 illustrates a flowchart for a method 15800 for 
controlling data. A data retrieval mechanism is provided in 
operation 15802 for retrieving data from a database. The 
data retrieval mechanism also writes data to the database. In 
operation 15804, the data retrieval mechanism is encapsu- 
lated in a data handler. A request from a domain object is 
received for a retrieval of a portion of the data in the 
database in operation 15806. The data retrieval mechanism 
is utilized in operation 15808 to retrieve the portion of the 
data from the database. The portion of the data is passed 
through the data handler to the domain object in operation 
15810 
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The data retrieval mechanism may be capable of being 
used by a plurality of domain objects. Also, the data retrieval 
mechanism may capable of being used by only one of a 
plurality of domain objects. Dependencies on the data 

5 retrieval mechanism within the data handler may also be 
managed via code generation. 

The data handler may physically partitioned into a com- 
ponent separate from the domain object. Optionally, the 
domain object may write attributes to a data stream. In such 

10 a case, the data handler may define an order in which the 
attributes are written to the data stream. Also, a row class 
may define the attributes in the same order as the attributes 
appear on the database. Further, the data handler may iterate 
over the attributes and may save them to the database. 

15 Business Objects in memory generally store and rctreive 
their data members from some type of persistent store. When 
using Individual Persistence, how can we ensure that the 
retrieval mechanism used by the domain object is indepen- 
dent of the business logic? 

20 Individual Persistence assigns responsibility for data 
access at the level of individual domain objects. Each 
domain object or class can retrieve, update, insert, and delete 
its data from a persistent store independently of other objects 
or classes. This promotes encapsulation and reuse across 

25 business transactions. 

FIG. 159 illustrates the data retrieval mechanism calls 
being placed directly within the domain object 15900 (in this 
example SQL is inserted into the Account business object). 
When persistence is at the class level, it is typical to code 

30 the actual SQL, serialization, or CICS call directly in the 
class itself. In the example shown above, an "Account" 
object can contain the SQL needed to retrieve and save its 
state to the database. 

This approach can reduce the flexibility of the domain 

35 object, in that, changes to the access logic or the badcend 
database must result in changes to the business object or 
class. How can we ensure that the business logic is inde- 
pendent of the data retrieval mechanism for such a class? 
FIG. 160 shows the interrelationship between a database 

40 16000, a persist 16002, and an account 16004. 

Biisiness objects delegate their data retrieval mechanism 
to an appropriate handler. This Data Handler can be either be 
generic or specific to each type of domain object used. Tb 
minimize the impact of changes, dependencies on the data- 

45 base schema or data retrieval mechanism within the handler 
could be managed via code generation. In this manner, the 
physical data access is separated from pure business logic. 

FIG. 161 illustrates that the database retrieval mechanism 
is separated from the business object 16100 by encapsulate 
ing the logic within a data handler 16102. 
Benefits 

Loose Coupling of Data Access. The bxisiness object is 
independent of the database access logic and the back- 
end database. As a result, the method by which the 
domain object accesses the persistent store can be 
changed without impacting existing source code. 
Distribution. Data handlers can be physicaUy partitioned 
into a separate component from the business logic. For 

60 example, the data handler could be on a data server 
component near the DB, while the business logic is in 
an application component. 
Multiple Data Handlers. Different strategies can be imple- 
mented based upon specific requirements. For example, 

65 on the client we can use serialization to communicate 
with the server; whereas the server can use standard DB 
access to communicate with DB. 
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Support for Testing. Similarly, during testing, hard-coded 
data handlers can be created to return dummy data. 
These can then be replaced at run-time or later in 
testing without impacting the code. 
The following information focuses on the implementation 
of the Data Handler pattern (TiMapper) and the separation 
of the business domain objects from the data retrieval 
mechanism used on the project 

FIG. 162 illustrates the TiPersistenceStream 16200 and 
TiMapper 16202. 

TiPersistenceStream and TiMapper 

Within the Rapid Batch Persist Service, objects save and 
load themselves by writing to or reading from a Persistence 
Stream. This is undertaken via the base class (UPersist) with 
specialized streaming code created via the Creation Code 
Generator. As a result domain objects are only "aware" of 
how to stream themselves, and not how the data storage 
mechanism works. 

The first attribute an object writes to the stream is its 
CLASS _JI>. The stream tiien expects the other attributes to 
be put to the stream in the order defined by the mapper class 
(the data handler). This relationship between data handler 
and domain object is controlled via a row class» which 
defines the attributes in the same order as they appear on the 
DB (this class is also created via the Code Generator). 

When the end of the stream is reached, the mapper class 
iterates over the list of attributes within the row and saves 
them via embedded Pro*C. When loading the reverse 
happens, in that, the mapper loads the information torn 
Oracle and then populates a row based upon the CLASS_1D 
pulled from the database. 
TiMapper 

A Mapper for a class contains the columns(s) and table 
that the class wiU be written to, the type of the data and the 
order that they will be read from/written to the stream. It also 
reads and writes rows of data from the database. It generates 
a where clause from the primary key information (PID). A 
database runtime context is obtained from the Transaction 
Service (using tiie current implicit transaction context). It 
also contains the code to query for sequence ids, for classes 
that use optimistic locking. 

The mapper contains the data retrieval mechanism that 
interacts with the Oracle database instance. As a result, if a 
different technology is used to interact with Oracle (e.g. 
stored procedures, embedded Pro*C, Method/3 Pro*C) only 
the mapper class needs to change. 
TiRow 

A row contains the data to be written to a database row 
from a stream or to be written to a stream from a database 
row. It knows the column names on the table and knows the 
order in which they are read from streams. 
TiMapperManager 

The mapper manager is responsible for creating mappers 
for a given CLASS_ID. Each type of mapper registers with 
the mapper factory when the shared object is loaded into 
memory (using the dynamic registration factory pattern). 
The mapper factory is a singleton read only object. 

The Factory pattern can be used to create the appropriate 
Data Handler for a specific business object. This pattern 
enables the data access method to be changed at nmtime 
(e.g. batch mode, online mode or Request Batcher). 

Hie Stream-Based Communication pattern can be used to 
stream the business object's data to the handler. The stream 
can then be either forwarded to a Request Batcher or can 
parsed and sent to database. 
Individual Persistence 

FIG. 163 illustrates a flowchart for a method 16300 for 
organizing data access among a plurality of business entities. 
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Data about a user is retrieved and packaged into a cross- 
functional data object in operation 1630K2 and 16304. A 
request for data is retrieved from one of a plurality of 
business objects in operation 16306. In operation 16308, the 

5 business object are directed to the data object such that the 
business object retrieves the entire data object The business 
object also selects the data from the data object. 

Both locking and integrity may use a uniform mechanism. 
The business object may retrieve account, customer, and 

10 bill-related data from the data object. Also, the business 
objects may be able to update themselves independentiy of 
each other. 

Optionally, new business objects may take advantage of 
existing data access routines. Also, each business object may 

15 use a tmiform access architecture. 

Create a data access architecture that supports reusable, 
independent business objects in the context of atomic, 
functionally-specific transactions. 
A business unit of work, or business transaction, typically 

20 acts on mtiltiplc business entities. But for each individual 
entity, the transaction might only display and update a few 
data attributes. 

For example, accepting biU payment over the phone 
might use the account number, customer name, amount due, 

25 date due, and credit card nximber. The transaction could 
therefore avoid accessing many attributes of the account, 
customer, or monthly bill entities. This might naturally lead 
to a data architecture which only fetches reqxured attributes, 
based on the transaction's needs. 

30 Indeed, a traditional client/server program retrieves data 
in a piecemeal fashion. In this case, the example program 
would typically allocate a single record to fetch and store the 
reqmred data items. Then, an "accept biU payment" data 
access module would fill this structure. This couples data 

35 access to processing function. 

FIG. 164 illustrates retrieving data piecemeal. 
This traditional style of data access may seem flexible. 
After all, developers can grab whatever data they need for a 
particular business transaction. 

40 But such access is very unstructured. Different pieces of 
a cohesive account entity, for example, scatter across mul- 
tiple windows. Some windows will use the account's effec- 
tive dale; others will not. 
This also introduces redimdancy. Retrieving the date 

45 requires determining the correct database, table, column, 
and type declaration. Yet another developer who needs this 
date, for a different data set, duplicates the effort. This does 
not encapsulate changes, thereby raising costs for testing, 
maintenance, and extension. 

50 Moreover, each transaction must hand-craft its own 
retrieval procedure. Creating the thousandth new business 
transaction would require creating a thousandth new access 
module. Yet all data items would already have been retrieved 
by other modules. This style of data access is not reusable. 

55 Finally, business entities are typically less likely to change 
than the transactions, or processes, which act on those 
entities. For example, an enterprise might re-engineer its 
biUing fimction. Regardless of the resulting process, the 
accoimt, customer, and monthly biQ objects would likely 

60 remain. Hiis suggests that transaction-based data access is 
brittle. 

Therefore, data access shotild be organized around busi- 
ness entities, rather than transactions. Individual Persistence 
packages data into cross-functional objects, rather than 
65 transaction-specific data structures. Each individual busi- 
ness object, instead of the window or application, manages 
the retrieval of its data items. 
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A business object provides public methods for accessing, unstreaming, message compression, and error handling, 

comparing, displaying, and setting that data. Developers can Moreover, business entities should support these capabilities 

therefore no longer plunder the persistent store, selecting through a consistent, polymorphic interface, 

data items at wiU. Instead, they must access their data For example, all business objects could respond to the 
through encapsulated, self-requesting business objects. 5 saveData message, to persist any changes. saveData could 

With this architecture, the example bilHng function first check, privately, if the objert 

retrieves account, customer, monthly bill, and bill payment using pnvate CRUD flags, it could determine whether a save 

i^^j. translates into an insert, update, or delete. Finally, saveData 

TTrr" iiwf^^f-^ tk- fk*. could stream out the business object's attributes, based on a 

FIG. 165 mustrates the manner in wh^ the present ^^^^^ ^ transaction persists its business 
mvention retrieve whole objects 16500 , ^" objects by simply iterating over the collection, sending each 

For reuse, busmess objects should be able to request and member saveData 

update themselves independenUy of each other. Separating architecture should also encapsulate the data access 

the data access for customer and account objects supports protocols or products. For example, whether the business 

reusing them in isolation. Objects should therefore avoid objects use a relational or object DBMS should be trans- 
explicitly requesting other linked objects, unless a formal 15 parent to calling programs. This minimizes the impact of 

containment relationship exists. changes to the storage technology. 

Finally, separation of concern allows business objects to Individual Persistence naturally leads to multiple, small- 
remain blissfully unaware of the transactions which use grained request messages per transaction. Request Batcher 
them. A business object will not know which data items or solves performance problems with multiple network mes- 
services it may need to provide to its clients. Thus, the object 20 sages. 

must bring back all its data. Data Handler encapsulates data access code from business 

Benefits objects. This protects business logic from changes in data 

Reuse. New transactions can take advantage of existing access protocols and products, 

data access routines. For example, introducing a new Request Sorter handles referential integrity and deadlock 
business transaction, like perform credit check, would 25 avoidance in a uniform manner, 

use existing customer and account objects. Yet, these Multi-object Fetch 

domain model objects would already know how to FIG. 166 illustrates a flowchart for a method 16600 for 

update themselves. Therefore, the new application retrieving multiple business objects across a network in one 

would build no new data access code, access operation. In operation 16602, a business object and 
Maintainability and extensibflity. Hiis approach supports ^ ^ Pl^^^i^V remaining objects are provided on a persistent 

"fix in one place." Any changes to particular data ^pon receiving a request for the business object m 

elements only need to be changed, tested, and recom- operation 16604, it is establidied which of the remaimng 

piled in one access module, that of the owning business objects are related to the business object in operation 16606. 

Q^Qf>l The related objects and the business object are retrieved 

TT 'c T» 1- • 1 1 • J r 1 • * 35 from the persistent store in one operation and it is deter- 

Umfonnity. Both optimistic locking and referential mteg- . j.^^. ^. . * w**t.u • 

/r»V\ * • 11 J J * *u u • w * mmed how the retrieved related objects relate to the business 

nty (RI) are typically defined at the busmess object u- 4 j u 4i. / *• ut^no ^ i£icin a 

cC., c*^,..,** .r.A object and each other (see operations 16608 and 16610. A 

level. For example, separate account and customer t.- \^t. ^ • jwju**- 

objects typically have their own locking attributes. In pph of relationships of the business and related objects is 

addition, an RI rule usually relates one entity to mstantiated m memory m operation 

^. ' . „ 1, / , . , „ 40 An object navigation pattern of accessmg the business 

another, such as "all accounts must have a customer. t.- . j • i u- %u *u i * ^ 

^ • - J * J u • • object and then accessing relationships with the related 

Organizmg data access around busmess entities sim- ,-1. . j* .- *i. i*ju-.Tn- 

i.f , f . J • * *t- -f objects may be used to retneve the related objects. The 

plines locking and mtegnty. Both can use a uniform / * . .t. i_ • ^ i * j * r 

. . • 1 • *t /*t- I.'* *. u'j relationships between the business and related objects for 

mechamsm, implymg that the architecture can hide ..... .i. Li?t.- i.- i uj. 

* u - 1 J * -1 J *u u J J- * If mstantiatmg the graph of relationships may also be deler- 

techmcal details. This avoids the hard-codmg typical of • * j- i.-. *t_-* j.t. 

the transaction based a roach mmed from a source object, a set of target objects, and the 

^ ^ ... / . . . , r „ name of the relationship. Additionally, the establishment of 

Flexibility. Whole object retrieval is ejrtensMe. It allows ^^^^ remaining objects are related to the business 

a transaction to ask an object for any data. This supports ^^^^^^ determination of how the retrieved related 

mamtenance and extension. A developer can easily ^^^^^^ ^^^^^ business object and each other may be 

chaiige the particular data items a transaction uses. But pi^-processed before retrieving the selected related objects 

whole retneval sUll guarantees that those items wiU ^^^^ ^^-^^^ persistent store, 

already have been retrieved. For example, a fixture ^ ^^^^^ ^ ^ion of the objects may also be 

release of the accept biU payment window could also ^^^.^^^^ ^ ^^^^^ ^^^^^ ^^^^^ 3 ^^^^^^ 

display the social security number. Yet the data access ^ ^he persistent store for retrieving the 

routines would need no modificaUon. remainder of the objects, 

^.^T? .^^'''^ ^M^^^ ^ "'"PP"'^ ^^""^"^^ It is not unusual to retrieve multiple business objects 

CRUD flag capabihUes, of: ^^1^^^^ ^ persistent objects 

^^^^^ involved in a unit of work be efficiently retrieved? 

Retrieve A given business object maintains associations to several 
Update 60 other busmess objects. A given unit of work needs to access 

Delete a subset of the defined associations. In order to perform the 

Hiis access architecture is uniform across business enti- unit of work, the business object and the reqiured subset of 

ties. The architecture can therefore standardize much of the associated objects must be retrieved &om persistent store, 

processing. For instance, the architecture can handle, across In the course of performing a unit of work, a set of related 
business objects: dirty checks, CRUD flag management, 65 objects needs to be accessed. Typically, one starts from a 

optimistic locking, rcfcreotial integrity, security checking, "root" object and **navigates** relationships to access related 

commit scope, request formatting, object streaming/ objects. This process can be repeated on the related objects. 
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An entire graph of related objects can be accessed in this 

manner. A natural way to retrieve these objects is through -continued 

lazy instantiation, i.e., objects are retrieved from persistent " TTTTT t. rMTTx^Bm r^u anncrani r» dtji a 

. V' • . J rw« . . • 1 HouscholdRclation5hips[NUMBER_OF_HOUSEHOLD_JlELA- 

store as each relationship is traversed. This retneval pattern tionships + 1] - {"Hobbyists^ o}; 

typically requires multiple database/network accesses and 5 static char * 

can have serious performance implications, especially over Hobbyisa<elationsiiips[NUMBEJL-OF_iNDiviDAUAU_RELA- 

vu-AM TIONSEDPS + 1] - {"Hobbies", "lateiests", 0}; 

^ ' , . . . , ^ . .1 static MuItiObjcctFctchSpec HobbyIateicsiMo£Sp«(5] - 

Therefore, a mechanism is needed to perform the retrieval ^ 

from persistent store in one access operation. This mecha- { household_ciassid, HouseholdRelationships }, 

nism includes: { HOBBYIST-CLASSID, HobbyistRelationahips }, 

{ HOBBY_ClASSID, EmptyRclationship }, 

Support for a declarative multi-object fetch statement { interest_classid, Eir^yRcladonshq> }. 

which defines what is going to be fetched. This multi- { o» o } 

obj ect fetch statement does two things. It declares what h 

is going to be fetched. It also declares how the objects — — ^— 

that are being fetched relate to each other. jhere is a class MuMObjectFetch that performs the fetch 

Retrieval of the persistent data corresponding to the and associates all of the related objects that have been 

multi-object fetch statement. fetched so that when these related objects are accessed there 

Instantiation of the graph of related objects in memory. is no fiirther access to the database. The MulliObjectFetch 

Benefits 20 class uses the MultiObjectFetchSpec to determine how the 

Performance. Performance is increased by making a objects fetched relate to each other. This implementation 

single trip across the network and a single database assumes that the persistent framework being used can fill in 

access to fetch several instances of objects that partici- the relationship given a source object, a set of target objects 

pate in a transaction. The savings can be especially and the name of the relationship, 

noticeable over a high-latency WAN. 25 

Continuity. Within the application code, the object navi- 

gation pattern of accessing an object and then accessing MultiObjcctFctch 

relationships from that object can still be used to access { 

objects. P^l^lic: 

1 u * t. V *u MultiObjectFetch *MultiObjectFctch( 

Complexity. Requires more elaborate architecture than MiatiObjectFetchSpcc "mofspec); 

lazy instantiation, PcKistcatobjcct *fctch< ); 

FIG. 167 illustrates an example of an implementation of RWOrdercd *fetchRDws( ); 

the Multi-Fetch Object 16700. ]^ 

FIG. 16S illustrates the Fetching of a Household object 

16800 along with the other related objects using the multi There is an assumption that the Household, Hobbyist, 

object fetch results . Hobby and Interest business objects inherits from a common 

FIG. 169 is an interaction diagram showing when the ba^e class, PersistentObject If the restriction on the house- 

multi object fetch is not used. hold is to bring back one Household, fetch( ) would used. If 

Note that if there is a large household, and each hobbyist ^ restriction on the Household will bring more than one 

in the household has lots of hobbies jmd interests, several Household, fetchRows( ) would be used. The fetch and the 

trips to the server will be made to ftilfiU this query. T^ere ^tchRows brings back the Household objects(s) and the 

needs to be a multi-obiect fetch specification that keeps w j ft • * u ul- j t * * 

.J,., ,1 1, j.^r.Lj Z related Hobbyists, Hobbies and Interests, 

enough detail to know what needs to be fetched and how the ^ 

fetched object will relate to each other. Here is a structure Static Approach (Using Stored Procedures) 

that win capture that information. A stored procedure would be written that would retrieve 

the Household object(s), Hobbyist objects related to the 

Household objects, Hobby objects related to the Hobbyist 

'~TrZ^ZT~r7ZZ objects and the Interest objects also related to the Hobbyist 

struct MultiObiectFetchSpec ^ . . , . , » 

{ 50 objects. It IS important that the stored procedure fetch the 

AxysClassid dftssid; objects in this order since the multi object fetch spec 

char -associfltionName; declared that this is the expected order. These fetched 

objects would then be passed to the MultiObjectFetch object 
which would fill in all the relationships of the retumed object 

This is a declaration of the multi object fetch using the 55 ^sing the fetch ^ecification. 

example above with the Household, Hobbyist, Hobby and . ^ ^ n ^/nj- a^- \ 

Inter^ Dynamic Approach (Dependent Requests/Fending Actions) 

The multi-object fetch can be pre-processed before send- 
ing the request to the database. Any objects that can be 
fetched from the cache will be fetched from the cache. The 

r™™™ ^ .o^T^ « remaining requests that cannot be satisfied from the cache 

const HOBBYKr_CLASSID = 2; n l . 1. . i_ * . *t_ j . 

const HOBBY_CLASSiD = 3; will then be Sent as a batch request to the database. This 

const INTEREST_CLASSID - 4; requires complex processing to determine if the cache can be 

const NUMBER„OF jousEHOiD_RELAnoNSHiPS - 1; ^tiis dynamic processing assumes that dynamic SQL 

const NUMBER„0F_INDIVIDAUAU-RELAI10NSEnFS - 2; ujfiiouji^ t^iuw^ooiu^ aoouiiiw uiai KiyuaiuiK.j^wL^ 

static char *EinptyRclatioQshq>[i] - { 0 }; 65 Will be used smce it IS not known at design time what objects 

static char * will bc found in the cache and what objects still need to be 

fetched from the database. 



}; 



const HOUSEHOLD_CLASSID = 1; 



60 
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Dependent Request — ^used in dynamic approach 
Request Batcher — ^uscd in dynamic approach 
Batching Update — similar to bathing of fetches but used to 
batch updates 

Relationship Stereotype — The setAssodation method is 

called to fill in the relationships 
Object Identifiers as Objects 

FIG. 170 illustrates a flowchart for a method 17000 for 
implementing an association of business objects without 
retrieving the business objects from a database on which the 
business objects are stored. In operations 17002 and 17004, 
a business object is provided and an instance of an associ- 
ated object is stored on a database. An association of the 
business object with the instance of the associated object is 
determined in operation 17006. In operation 17008, an 
object identifier is generated containing information includ- 
ing the determination association which is necessary to 
retrieve the instance of the associated object from the 
database. The object identifier is loaded when the business 
object starts in operation 17010. A location of the instance 
of the associated object on the database is determined in 
operation 17012 firom the object identifier and the instance 
of the associated object is retrieved from the database in 
operation 17014. 

The object identifier may be used to provide a unique 
identity that is required for implementing caching and 
identity management. Also, the object identifier may include 
a unique row identifier generated by the database, an iden- 
tifier generated by a utility, and/or a unique string generated 
from one or more attributes. As an option, different types of 
business objects may be provided. In such a case, a different 
class of object identifier may be generated for each type of 
business object. As another option, the determination of a 
location of the instance and the retrieval of the instance of 
the associated object may also include the taking the object 
identifier as an argument and returning the instance of the 
associated object. 

Most useful business objects have a relationship, or 
association, with other business objects. How should this 
association be implemented without having to read the 
associated object's state from the database? 

Most useful business objects have a relationship, or 
association, with another business object instance. 
Traditionally, this relationship is expressed as a pointer or 
reference to the object. However, pointers (and references) 
are memory constructs valid only so long as the object slate 
exists in memory. When storing the object to a persistent 
storage medium (such as a relational database) these asso- 
ciations need to be expressed in some other way. Likewise, 
when the object is restored firom persistent storage, the 
associations need to be reinitialized since it is imlikely that 
the associated object will reside in the same memory loca- 
tion. If the associated object is stored in the persistent 
medium, this usually involves restoring it as well. This can 
become a long and expensive process if the association 
graph corresponding to the restored object is large or com- 
plex. It is particularly undesirable if the associations are not 
even traversed by the application. 

Therefore, implement the associations using object iden- 
tifiers that contain the necessary information to retrieve the 
object if it is needed. These objects can then be loaded when 
the object is restored, eliminating the need to restore the 
entire associated object In addition, since these object iden- 
tifiers uniquely identify an object instance, they can be 
used/passed in place of memory pointers. When the object is 
needed, simply restore the instance using the object identi- 
fier. 
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Benefits 

Performance. Objects are retrieved only when they are 
needed. 

Caching and identity management. Object Identifiers can 
5 be used to provide the unique id needed to implement 
caching and identity management 
The object identifier (or OID) must contain enough infor- 
mation to uniquely identify the instance. Tliis identifier 
could be a unique row id generated by a database, a UUID 
10 generated by a utility or a unique string generated from one 
or more attributes. It is generally desirable to have a different 
class of OID for each type of object, thereby creating a more 
type-safe environment. It should also be noted that OID's 
should have value semantics. 

In addition, a mechanism must be available to retrieve 
objects given their OID. This can be as simple as a static (or 
class) method such as getByld that takes the OID as an 
argument and returns the instance of the object. A more 
sophisticated approach would be to implement this and other 
2Q persistence related methods in a generalized utility class. 
Below is a simple example that illustrates the relationship 
between two classes using object identifiers. Please note that 
this example is an extreme simplification. A useful imple- 
mentation of this pattern would exist as part of a persistence 
^ framework that would include many additional methods and 
abstractions. 



class Foold 
30 public: 

// accessors, coastmctois and destructors 
private 

long_Jd; 

}; 

class Foo 

35 { 
public: 

// accetusoTS, constiuctois and destructors 
static Foo* getByIdCFooId& id); 

}; 

class Bar 

^ public: 

Foo* getFoo( ) 

{ 

return FoQ::gctById(Foo[d); 

// The calkr now owns the instance of Foo. Use of an 
// auto^tr here is highly recommended. 

45 } 

private: 

Foold_foold; 

); 



50 Collaborations 

Identity Manager — ^Uses Object Identifiers as unique 
key's for storing persistent slate objects. 

Persistent State Separate firom Persistent Object — Uses 
Object Identifiers embedded in persistent state objects to 

55 eliminate coupling. 
Object Identity Cache 

FIG. 171 illustrates a flowchart for a method 17100 for 
mapping of retrieved data into objects. An object is retrieved 
from a data store and cached in operations 17102 and 17104. 

60 A unique object identifier is assigned to the object in 
operation 17106. The object identifier is mapped to a rep- 
resentation of the object in a dictionary in operation 17108. 
When a request for a reference to the object is received in 
operation 17110, the object identifier of the object is 

65 retrieved from the dictionary in operation 17112, The 
requested reference is associated with the representation of 
the object stored in the dictionary in operation 17114. 
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In one embodiment, a data stoie may be accessed if the 
object identifier is not found in the dictionary to retrieve the 
object so that the process may be repeated with the retrieved 
object. In another embodiment, a query may be performed to 
retrieve multiple objects. A check may be performed to 
verify that each object is already cached so that objects not 
already cached may be cached. 

Also, if an object in the cache has changed since read, an 
error may be raised if the object retrieved has changed since 
read and the object retrieved may be ignored if the object 
retrieved has not changed since read. If an object in the 
cache has not changed since read, the object in the cache 
may also be replaced with the object retrieved if the object 
retrieved has changed since read and the object retrieved 
may be ignored if the object retrieved has not changed since 
read. Further, if a query is guaranteed to return at most a 
single object, the cache may be used prior to going to the 
data store by sequentially applying the function to each 
object in the cache and implementiDg a predicate function 
which answers whether or not a given object satisfies the 
query. 

Within a client context (e.g., a logical unit of work), the 
same object may be referenced more than once. How can 
object identity be preserved and redundant accesses to 
persistent store be avoided? 

(Although this pattern is not specific to relational 
databases, we wHl, for the sake of ooncreteness and clarity, 
describe the pattern in terms of an object-to-relational 
mapping.) 

Objects can be stored in and retrieved from a relational 30 
database. A retrieval strategy that simply translates relational 
data into objects in memory will almost certainly result in 
the instantiation of multiple copies of the same object. 
Furthermore, such a strategy is inefScient as the same data 
may be repeatedly and unnecessarily read from the database. 35 
This violates object identity and contributes to performance 
problems. 

Suppose the class Account has an association with the 
class Customer. Suppose the instance of Account ABC is 
associated with the instance of Customer 123. The following 40 
demonstrates multiple requests to Customer 123. 
Example 

customerl23=getCustomer(123) 
accountABC=getAccount(ABC) 

secondRefererenceTo Customer 12 3= 45 
accounlABC.getCustomeT( ) 
Note that customerl23 and secondRefererenceToCus- 
tomerl23 are the same customer. In this scenario, the desired 
behavior is to have the data store accessed once for cus- 
tomerl23. Also there should only be one instance of cus- 50 
tomerl23 in memory. Customerl23 and secondReferenc- 
eToCustomerl23 should reference this instance of the 
customerl23. 

Therefore, the mapping of retrieved data into objects 
should be mediated by an Identity Cache. FIG. 172 illus- 55 
trates an Object Identity Cache. 

Logically, an Identity Cache is a dictionary which, for 
each cached object, maps a unique object identifier to a 
representation of the object. Each object must be assigned an 
object identifier (OID) which uniquely identifies the object 60 
over the life of the system. 

The mediation mechanism works as follows: When a 
reference to an object is requested, the identity cache is 
consulted. If the object's OID is found in the cache, the 
requested reference is associated Avith the representation of 65 
the object stored in the cache. If the OID is not found in the 
cache, the data store is accessed. The object representation 



that is retrieved from the data store is inserted into the cache 
and the requested reference is associated with it. 
Benefits 

Performance. Performance is improved for frequently 
accessed objects since they are only fetched from the 
database once. 
Identity Preserved. Object identity is preserved since 

objects are cached based on the objects OID. 
A dictionary can be used to implement the Object Identity 
Cache. The following points should be considering when 
implementing an Object Identify Cache. 

A query could be performed that returns multiple objects. 
Each object that is retrieved must be checked to see if it is 
already in the cache. If it is not in the cache it must be 
inserted. The following shows what should be done when an 
object is retrieved that is already in the cache to get is 
correctly inserted into the cache. 



Object retrieved has 
clianged since read 



Object retrieved 
has not changed 
since read 



Object in cache has 
changed since read 



Object in cache has not 
changed since read 



Raise an error. At 
commit transaction 
there will be an 
optimistic lock failure 
so it is better to raise 
it now. 

Replace the object in 
cache with the object 
retrieved since the 
retrieved object is 
newer. 



Ignore the 
retrieved object, 
the object in cache 
is newer and the 
changes should not 
be losL 
Ignore the 
retrieved object, It 
is already in the 
cache. 



If the object is not in the cache when the object is 
retrieved, a simple insertion into the cadie can be done. 

If a query is guaranteed to return at most a single object, 
the cache may be used prior to going to the database by: 
implementing (for a given class) a predicate function 
which answers whether or not a given object satisfies 
the query 

sequentially applying the function to each object in the 
cache. 

A multiple row query must go to the database unless there 
is a mechanism to indicate that the class is completely 
cached. This is applicable to static reference data. 

life Time of cached objects can affect Cache size. If life 
time of the cadie is associated with a transaction there will 
be no problem. If the life time of the cache is associated with 
a longer lived entity sudi as a thread or a process, removal 
of objects from the cache must be actively managed. IWo 
commonly used strategies are reference counting and LRU 
purging. 

Collaborates with 

Object Relational Query pattern describes a mechanism 
for storing objects in a relation database. 
Object Identity 

Persistent State Separate from Persistent Object 
Used by 

Context Management 

Each Context (e.g., transaction, thread, etc.) owns an 
Identity cache which holds all of the objects in that context. 
Persistent State Separate from Persistant Object 

FIG. 173 illustrates a flowchart for a method 17300 for 
separating logic and data access concerns during develop- 
ment of a persistent object for insulating development of 
business logic from development of data access routine. A 
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persistent object being developed is accessed and a state of 
the persistent object is detached into a separate state class in 
operations 17302 and 17304. The state class serves as a 
contract between a logic development team and a data 
access development team. Logic development is limited by 
the logic development team to developing business logic in 
operation 17306. In operation 17308, data access develop- 
ment is restricted by the data access development team to 
providing data creation, retrieval, updating, and deletion 
capabihties. 

The business logic team may develop persistent objects 
that manipulate the state of the persistent object in accor- 
dance with business requirements. In one embodiment, the 
state may be implemented as a structure of values of basic 
data types. In another embodiment, the state class may 
contain member variables of lower data types including 
basic data types, extended basic data types with value 
semantics, other state classes, and/or vectors of the basic 
data types, the extended basic data types with value seman- 
tics and other state classes. 

Optionally, the state class may support data structures of 
arbitrary shapes. Supporting classes may manipulate the 
state in a polymorphic fashion. As another option, the state 
may be further implemented as a class that contains key- 
value attribute pairs. The state class^ may also contain a 
keyed data structure containing attribute names and attribute 
values. Additionally, the slate can also be asked to write data 
to a stream. 

When designing and implementing persistent objects, 
how do we effectively insulate the development of business 
logic from the development of database access routine? 

Given the use of a relational database as the persistent 
store, the scope of a persistence architecture can range 
across the following levels of transparency and automation: 
Heavyweight, fully-automated persistence architecture. ^5 
Including the mapping of the object model to the 
database schema and generation of all the database 
access code 

Variants of the above scheme allowing the customization 

of database access code 
Lightweight mechanism which provides generic persis- 
tence capabilities to business objects but delegates all 
database access to separately developed data access 
routines. In this case, the data access routines are not 
part of the persistence architecture per se. 
Minimal persistence approach in which each business 

object is directly responsible for database access 
From a persistence perspective, no matter which of these 
approaches is used, development of the system and archi- 
tecture presents two distinct challenges to the development 
team. The hrst challenge is to accurately represent the 
business logic as a collection of business objects that include 
interfaces for performing the correct set of functionality. The 
second challenge is to be able to create, retrieve, update and 
delete (CRUD) records that represent the state of these 
business objects from the database in an efficient fashion. 

Data access and business logic are significantly different 
tasks both in their goals and development approaches. 
Consequently, except when a fully automated persistence 
architecture is used, it is often the case that two separate 
teams are responsible for the development of business logic 
and data access. If both teams work directly with the 
business objects, serious contention may result. Problems 
encountered in practice include: 

Changes to business logic that impacts the development 
(e.g., requires recompilation) of database access code 
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even when there is no change to the attributes of 
business objects. (Note: recompilation can be a prob- 
lem even if a fuHy automated persistence framework is 
used.) 

Changes to the database schema can impact the develop- 
ment of business objects 

The data access team may tmduly influence the design of 
the business objects, leading to a data-centric model 
and design 

The two teams' development schedules need to be in 
sync; slippage on one team can adversely impact the 
other team's progress 

Therefore, detach the state of the business object into a 
separate state class that can be agreed upon and completed 
prior to the start of significant development by either the data 
access team or the business object team. This class should be 
nothing more than the raw data (preferably basic data types) 
used to represent the state of the object. Tlie business object 
contains all business logic and a reference/pointer to an 
instance of the respective state class. This allows the devel- 
opment of business logic and data access to proceed in 
parallel with the state class serving as a contract between the 
two teams. 

Using this approach, it is important to limit data access 
focus to providing CRUD operations (i.e., no business logic 
provided by stored procedures). The purpose of the data 
access portion of the application is to provide essential 
access to the data used by the bxisiness objets, and deliver 
this data in the most efficient way possible. Likewise, the 
purpose of the business object team is to develop business 
objects that manipulate the state of the object in accordance 
with the business requirements. Maintaining this separation 
insures there is no overlap between the development teams. 
Benefits 

Development Time. Data access and business logic can be 
developed in parallel reducing overall development 
time. 

Separation of concern. Data access remains separate from 
business logic, improving the understandability of the 
design. 

Testability. Business objects can be more easily devel- 
oped and tested based on data access stubs, thereby 
reUeving the business object development teams from 
dependencies on the data access classes and the data- 
base libraries. 

Caching and identity management. Separating the persis- 
tent state from the persistent object can be leveraged to 
aid in managing multiple class instances that represent 
the same entity (see the Object Identity Cache pattern). 
Object distribution. Separating the persistent state from 
the persistent object can aid in passing state in a 
distributed system. In cases where in is necessary to 
pass an object as an argument to a distributed method, 
it is more desirable from a performance perspective to 
pass the object's state as opposed to a remote reference. 
A new instance can then be created from the state, 
manipulated locally and then returned to the caller. 
The persistent state can be implemented in a variety of 

ways depending on the requirements of the system. They can 

roughly be described by the following 

Implement the State as a Structure of Values of Basic Data 

Types 

Each business object class has an associated struct. This 
is the most straightforward approach, although also the least 
flexible. With this approach, the business logic may need to 
manipulate lower level data types contained in the state 
object. 
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Supporting classes which need to manipulate the state 
object (in order to retrieve data from the database or pass the 
value between processes) need to be knowledgeable about 
the struct data type to manipulate it. In addition, copying the 
struct may be non-trivial if it contains dynamically allocated 
memory. 



struct State_JData 



{ 



}; 



long id; 
char codc[8]; 
string value; 



15 



Implement the State as a Class Containing Member Vari- 
ables of Basic Data Types 

1. Implementation using a "developer-friendly" state 
class: A state class can contain basic data types (except 
char*), extended basic data types with value semantics 20 
(e.g., currency, String), other state classes, and vectors 
(not arrays) of all of the above. This does not, however, 
imply that the class is a flexible (dictionary-like) data 
structure. These state classes could/should all inherit 
from a common abstract base class which defines (but 25 
does not implement, at least in C++) a serialization 
protocol (Java is a different story than C++ because 
everything is serializable almost by default). 



class StateCiass 
public: 

virtual void iead(Streain inStream) - 0; 
virtual void WTite(Streani outStream) - 0; 

}; 

class StateData : public StateCiass 
{ 

public: 

virtual void iead(Streaiii inStream); 

// implcDientation reads state data fiom stream, 
virtual void write(Strea[n outStream); 

// impletnentation writes state data to stream. 

Private: 

long id; 
char codc(8j 
string value; 



}; 
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2. Implementation using an enhanced kind of the class 
described in (A) but which also happens to be a flexible 
data structure (in the sense that the same class can, 
similar to a dictionary, support data stmctures of arbi- 
trary shapes). 

This approach provides more flexibility since some com- 
mon behavior can be abstracted into a base class. In 
addition, supporting classes which need to maniptdate 
the state object (in order to retrieve data from the 
database or pass the value between processes) can do so 
in a polymorphic fashion. Also, copy constructors and 
destructors can be used to handle dynamically allocated 
memory. 

Implement the State as a Class that Contains Key-value 
Attribute Pairs 

Hiis is an alternative approach to the one listed above. 
Using this technique the state class would contain a keyed 
data structure (e.g. a dictionary) containing keys (the 
attribute name) and values (the attribute value). In cases 
where you want to copy the state or pass it to another 
process, the supporting code does not need to know the type 



of the state object it is working with. State objects can 
simply be asked to read or write their data to and from a 
stream or string. While this offers a more dynamic solution, 
it should be noted that with this solution additional logic 
would need to be included in the persistent object to insure 
the validity of the associated state class. 

In all of these approaches, another important concept is 
the implementation of associations between objects. In 
general, the best approach is to store these as Soft Refer- 
ences to the other objects as opposed to actual pointers. This 
illuminates the need to load a large graph of objects when 
only one is needed, as well as easing the question of whether 
to implement a deep or shallow copy. 

Identity Manager Manages a collection of persistent state 
objects for a given class. 

Context Manager: Used in conjunction with Identity 
Manager to maintain separate collections of persistent state 
objects for separate application contexts. 

Lazy Instantiation: Restores persistent state object for a 
given object instance on-demand. 

Object Identity Cache: Caches persistent state objects 
referenced by persistent objects. 
Piecemeal Retrieval 

FIG. 174 illustrates a flowchart for a method 17400 for 
providing a warning upon retrieval of objects that are 
incomplete. An object is provided with at least one missing 
attribute in operation 17402. Upon receipt of a request from 
an application for the object access to the attributes of the 
object is allowed by the application in operations 17404 and 
17406. A warning is provided upon an attempt to access the 
attribute of the object that is missing in operation 17408. 

The warning may include information on how to handle 
the missing attribute. An impHcit transaction may also be 
called by the object upon the attempt to access the attribute 
of the object that is missing. In addition, an explicit trans- 
action may be called by the object upon the attempt to access 
the attribute of the object that is missing. Also, the transac- 
tion may also include finding the attribute that is missing. 

When legacy transactions don't allow object or entity 
based retrieval, how do we retrieve useful objects? 

Object and component based projects designed and built 
from the ground up will likely have a well thought out 
component model and architecture where GUI widgets are 
linked or bound to domain objects. Data access (and 
retrieval) for these objects is organized around the business 
entity, rather than a transaction, and so data is packaged into 
cross-functional objects, rather than transaction-^ecific 
data structures. Each business object manages the retrieval 
of its data items. 

These domain objects provide public methods for 
accessing, comparing, displaying, and mutating data. 
Therefore, developers wifl only access data through these 
encapsulated, self -requesting domain objects. (See Indi- 
vidual Persistence). 

For example a hilling application that accepts biU pay- 
ment over the phone might use the accoxmt number, cus- 
tomer name, amount due, date due, and credit card number. 
With an Entity-Based Data Access architecture, the account 
17500, customer 17502, montiily bill 17504, and bill pay- 
ment objects 17506 will all be retrieved. FIG. 175 illustrates 
an Entity-Based Data Access System. 

This architecture is preferred if conditions allow, however 
legacy programs usually retrieve data through transaction or 
message based systems. These transactions often have two 
notable characteristics. One, a business unit of work or 
business transaction often acts on multiple business entities, 
and two, for each individual entity, the transaction might 
only retrieve and update a few data attributes. 
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Using the same bill payment example, a legacy system Transaction Service Patterns (1012) 

might utilize a 'accept bill payment' transaction. This trans- Transactions and LUWS 

action woaild require only a small portion of the attributes for A transaction is a set of business events that, coupled 

the account, customer, or monthly bill entities and so the together, accomplish a particular business function, suci as 

data would be retrieved piecemeal only as required by the 5 turning on gas service. Because the events are logically 

transaction. related, their data changes are logically related as well. 

FIG. 176 illustrates a Retrieving Data Piecemeal System. Taken together, these data changes create a new, consistent 

In this case, the transaction would allocate a single record state for the business model, 

(an *accountPaymentData* 17600 structure as shown in the while a transaction is in process, the state of the business 

Figure) to fetch and store the required data items. This modelmaynotbeconsistent,soitisnec6ssary to manage the 

structure would then be used to populate the business entire transaction from its point of origin to its point of 

entities. completion. Whether the transaction is successful or not, the 

As a result, domain objects are left incomplete and point of completion will always result in a steady, consistent 

therefore unsuitable for use by all services. This forces the state for the business model. For successful transactions, 

developers of services to know and understand the use of 15 data changes wiU be committed and the business model will 

transactions to retrieve objects. reflect all new business data associated with the transaction. 

Therefore, when legacy circumstances dictate, retrieve For failed transactions, data changes will be rolled back and 

data piecemeal, on a transaction basis as necessary rather the business model will appear as it did prior to the start of 

than as complete business entities and develop mechanisms the transaction. 

to handle access and updates to missing attributes of piece- 20 To help manage the transaction from point of origin to 

meal objects. point of completion, each transaction is organized through a 

By default, objects should return a warning when a single Logical Unit of Work (LUW). This LUW manages the 

missing attribute is accessed with no other means to retrieve business model and any of its subsequent data changes, 

it. This warning would simply let calling applications know while both users and internal exceptions can determine the 

that an attribute is missing or unavailable. The calling 25 success of a transaction, the LUW handles the commit and 

application would then have to determine how to handle rollback operations. 

these missing attributes. FIG. 177 illustrates a Commit and Rollback routine 

A preferred approach to handling missing attributes would 17700. 

be to use multiple overlapping transactions. While, each ^s transactions become more complex and require a 

transaction might only populate a part of the object, the 30 greater scale of changes to the business model, the LUW 

transactions taken together assemble complete objects. trying to manage these changes becomes large and unwieldy. 

This use of overlapping transactions could either be Tosimplify these transactions, the LUW is broken down into 

implicit or explicit to the objects. An implicit transaction nested, more granular, logically related units of work called 

would be called by the object when a missing attribute is Secondary LUWs. Secondary LUWs are identical to LUWs 

accessed. This method of lazy retrieval may be preferable 35 except that their commit and rollback operations affect only 

because it is transparent to the calling application. the business model of their parent LUW and are not per- 

An explicit transaction would be called by a task inde- sisted to a data store. Consequendy, a secondary LUW must 

pendent of the object. Note however, that explicit transac- manage its data changes differently than its parent 

tions would either require that the task holds the object or piG. 178 illustrates Nested Logical Units of Work, 

that an object identity mechanism is used to find the existing 40 One method for managing changes to the business model 

object rather than create a new one. involves copying the model into the secondary LUW. 

In some cases, new transactions can be created for the Another often simpler approach is to store both old and new 

explicit purpose of retrieving full or partial business entities. (or potential) values for all objecte in the business model. 

This approach requires a thorough knowledge of the legacy Transaction Patterns 

system. 45 in the process of managing its business model, a LUW 

In other cases, the legacy code can be opened and the will often have to send messages to all business objects 

transactions modified to bring back additional data. Care within the LUW. Examples of such messages include 

should used when doing so as legacy code is often fragile saveDataChanges, retrieve, or isDirty. Rather than hardcod- 

and poorly documented. ing a call to each object in the model, the pattern LUW 

Benefits 50 Context suggests using a bag (or collection) to hold all 

Legacy Reuse. The overwhelming benefit of piecemeal objects referenced by the LUW. Then, a single message can 

retrieval is that it enables reuse of legacy systems. be sent to the bag which will forward it to all objects within 

Clients generally have a substantial investment in their it. 

existing systems and they will be hard pressed to Support for user multi-tasking can also present problems 

convert them to component based systems built on S5 for LUWs. Through multi-tasking, multiple LUWs will be 

objects. This pattern allows new systems to reuse running concurrently. Problems occur if the business models 

existing business logic through their transactions. of these concurrent LUWs overlap and the transactions 

Performance and Impedance. Objects based on transac- attempt to write to the same business object. A call center 

tions typically bring back only that data which is representative trying to solve two customer problems during 

needed. The transaction is typically mapped directly to 60 the course of one call is one example of this scenario. The 

change that the user is trying to make. This improves Separate Models pattern helps solve this issue by assigning 

performance by reducing the number of network calls each LUW independent copies of their portion of the busi- 

and only bringing back data that is needed. ness model. Tliis keeps one transaction from interfering with 

Individual Persistence organizes data access around busi- another 

ness entities rather than transactions. 65 There are also several patterns that address problems 

Object Streaming handles the conversion of data from the related to sending transactions across the netwodc These 

structures received from transactions into business objects. patterns typically focus on minimizing network messaging. 
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When an LUW is called to commit, the transaction will Additionally, the pointer may be a configurable field of 

assemble the necessary objects from the business model to the dependent request. The requests may also be reused 

send their data changes to the information services layer independently of each other. In event another aspect of the 

This group of objects will include all new and dirty objects present invention, the dependent request may wait for the 

as well as aay objects marked for deletioQ. For each business 5 parent response at the server for minimizing network traffic, 

object, the transaction wiU likely have a corresponding During retrieval, one request may depend on the response 

request. If each of these requests were then sent to infor- ^^^^ ^o^" ^^^^^t. Nevertheless, ensure that a sii^e 

mation services independendy, a large number of network network message contains both requests, while using 

messages would result. To solve this problem, the Request Request Batcher. u- , u ■ 

D * u ** u * u 11 * • ♦ J *!. A busmess transaction typically acts on multiple business 

Batcher pattem batches all requests associated with a trans- lo ^^^^^ ^^^.^^^ ^ ^^^^^ mintenance window, which 

acUon together into one network message. On the other end information from account, customer, credit profile, and 

of the network. Information services would unbatch the home and work addresses. Given a unique account identifier, 

transacUon requests and persist the data changes. business transaction can retrieve all five objects. 

Another problem that may arise when multiple requests q^^.^ ^^e account retrieves all of its data, it will know its 

are sent for a given transaction is deadlock. Deadlock occurs 15 unique customer identifier. The customer can then retrieve 

when two requests are trying to lock the same pair of objects. fts own data, which includes the identifiers for the credit 

Each request locks one object and waits to commit until it profile and both addresses. Finally, the profile and addresses 

can lock the other. TTierefore, each request will wait for the can retrieve their data. In this case, profile and address 

other to complete while neither is able to do so. The Request retrieval depends on customer data; customer retrieval in 

Sorter pattem works with Request Batcher to handle this 20 turn depends on account data. 

problem by sorting requests as they are being imbatdied by However, Individual Persistence requires that each object 

Information Services. A request is not allowed to proceed have its own, independent request module. That is, cuslom- 

until any dependent requests are completed. ers do not always need accounts to be retrieved. After a 

During retrieval, one request may depend on the response customer's unique identifier has been filled in— regardless 

data for another request. For example, a business transaction 25 of by whom— it retrieves its data independently, 

that tries to retrieve a customer when given a customer ID theory, this independence is not an issue. The account 

wiU probably also want to retrieve the customer's address. co^l^ first get its data. After the customer's identifier was 

However, the transaction won't have the address ID until the filled, the customer could send its own request, 

customer is retrieve. Thus mxiltiple network messages are In practice, however, sending multiple messages, in series 

required when one request is dependent on another. The 30 this, degrades network performance. Request Batcher 

Dependent Request pattem solves this problem by allowing 1^000 provides a solution which bundles up requests into 

a batched request to indicate that it depends on another network message, thereby minimizing traffic. FIG. 180 

request. illustrates a Batching Retrievals and Dependency. 

As these patterns demonstrate, there is a high degree of This batching framework applies not only to update 

correlation between Transaction Services and Information 35 messages. For retrieval as well, one overall, batch request 

Services. Many of these transaction patterns require an receives one batch response. Yet an individual batched 

understanding of Information Services patterns. Two such request may depend on the response data from another 

examples are Individual Persistence and Piecemeal batched request. The serial nature of the two requests must 

Retrieval. It is recommended that these patterns be read and be preserved, even while the requests actually go in the same 

understood prior to using Request Batcher, Request Sorter 40 batch, in parallel. 

and Dependent Request. Therefore, additional mechanisms should aUow a batched 

Dependent Request request to indicate that it depends on another request. If a 

FIG. 179 illustrates a flowchart for a method 17900 for business object does not have its primary key— or other 

allowing a batched request to indicate that it depends on the attributes guaranteeing a unique match— it becomes a 

response lo another request. A group of business objects 45 Dependent Request. Because a dependent cannot fetch itself, 

necessary for a transaction are provided in operation 17902. soj^e other business object will inevitably have the neces- 

Logically-related requesu received from the business sary foreign key The dependent request will therefore 

objects are batched into a single network message in opera- register its dependency on this other object, 

tion 17904. One of the requests is a parent request. Received This object, the parent request, can have multiple depen- 

from the parent request in operation 17906 is a register that 50 dents. The aforementioned customer had credit profile and 

at least one of the requests is dependent upon the response address dependencies. This implies the need for an arbi- 

data. The network message is sent across a network and the trarily large collection of dependent requests. A dependency 

requests are unbundled from the network message in opera- collection can even include requests for multiple instances 

tions 17908 and 17910. Upon receipt of a response to the of the same class. This was the case with two address 

parent request in operation 17912, data is directed from the 55 requests depending on the same customer, 

response to the parent request to the dependent request in FIG. 181 illustrates the Dynamically Setting Dependency, 

operation 17914. Received from the response to the parent Dependencies should not be hard-coded. Any business 

request is a response to the dependent request based on the object can register as dependent on any other object which 

received data in operation 17916. can provide the necessary data. 

Hie dependent request may not have a primary key. In 60 manner, dependencies can be set at run-time. This 

such situation, the response to the parent request may could happen while building the model, or as requests 

include the primary key for allowing the dependent request register with Request Batcher, 

to be responded to. As another option, the dependent request Benefits 

may also include a pointer indicating that the dependent Performance. This solution supports request batching for 

request is dependent on the parent request. In this situation, 65 retrieving interdependent models, 

the pointer may be passed to the parent request during the Reuse. Because dependencies are not hard-coded, busi- 

step of batching the requests into the network message. ness objects can be reused independently of each other. 
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Loose Coupling. When a request dynamically registers its 
dependency, it need not know anything about its parent 
request The dependent effectively says, "I don't know 
who you are, but I know that your response data 
contains my identifier." 5 
Dependent Request would be irrelevant were it not for the 
"transaction impedance mismatch." This mismatch means 
that transactions no longer map one-to-one to access mod- 
ules. Individual Persistence is the approach which dictates 
that each business entity have its own independent access lo 
module. 

Request Batcher solves the performance problems of 
sending multiple, small-grained request messages over a 
network. But the resultant single message must support 
dependencies, with Dependent Request or a similar mecha- 15 
nism. 

LUW Context 

HG. 182 illustrates a flowchart for a method 18200 for 
sending a single message to all objects in a logical unit of 
work. A group of business objects necessary for a transaction 20 
are provided and managed in a logical unit of work in 
operations 18202 and 18204. A receiver is created which 
communicates with the business objects in the logical unit of 
work in operation 18206. Upon receiving a message for the 
business objects in the logical unit of work in operation 25 
18208, the message is directed to the receiver in operation 
18210. The receiver also forwards the message to each of the 
business objects in the logical xmit of work. 

Several groups of business objects necessary for a trans- 
action may also be provided with each group of business 30 
objects being managed in a separate logical unit of work. 
Also, a separate receiver may communicate with each group 
of objects. As another option, a request batcher in commu- 
nication with the receiver may also be provided for batching 
requests from the business objects for delivery. In such an 35 
embodiment, the request batcher intercepts the requests 
from the business objects and holds the requests until told to 
deliver the requests by an activity associated with the logical 
unit of work. 

Optionally, the receiver may hide technical details includ- 40 
ing details of persistence and garbage collection from busi- 
ness developers. As a further option, the business objects 
may be distributed across a network. Also, the receiver may 
distribute the message to each of the business objects across 
the network. Additionally, the logical unit of work may 45 
optionally be modeled as an object in software. 

Applications often need to send technical messages, like 
saveDataChanges( ) or release( ), lo all business objects in 
an LUW. Do this in a consistent manner and hide technical 
details from business developers. 50 

Cbnsider an Account Payment window, which displays 
information about an Account, Customer, Monthly Bill, and 
Payment. This window occasionally needs to send generic, 
technical messages to all business objects within its LUW. 
This messaging has nothing to do with the window's 55 
application-specific behavior. In fact, the other windows in 
the system need to send the same, generic messages to their 
LUW business objects. Although the business objects 
receiving these messages differ from window to window, the 
messages remain the same. 60 

In addition, this messaging typically has an arbitrary 
order. All that matters is that all business objects eventually 
receive the same message. 

For example, the window might use Individual Persis- 
tence. Then, when the user decides to save the window, all 65 
business objects receive a message like saveDataCbanges( ). 
The resultant pseudo-code would look hke: 
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AccountPayineiitActivity;:savcDataChaiigC5( ) 

{ 

// Propagate along the save meuage to all business 
// objects in my LUW. 
this.g&tAccount( ).saveDataChanges( ); 
this.getCustomer( ).savcDataCljanges( ); 
this.getMonthlyBill( ).saveDataClianges( ); 
this.getBillPaymeiit( ).saveDataChange8( }; 

} 



A retrieveData( ) message might also be required, if the 
object model pre -instantiates objects before retrieving them. 
Similarly, refresh( ) could be used: the business object, if 
dirty, replaces any changps with data originally from the data 
store. 

Even without Individual Persistence, there are other com- 
mon messages the window may want to send. For example, 
distributed objects typically need to be told when their 
memory can be reclaimed. COM+ uses the well-known 
method releaseRef( ), whereas some implementations of 
CORBA use release( ). Regardless, this is a common mes- 
sage that would also need to be sent to the business objects, 
similar to the saveDataChanges( ) propagation above. 

Dirty Flag provides another example. Here, the window 
accumulates the results of dirty checking, as follows: 



AccountPaymentActivity:dsDirty Q { 
// Return true if any single business object in the LLW is dirty, 
return 

(thLS.getAccaunt0.isDirtyO oi 
t]iis.getCustO[ner0.isDiityO or 
this-gctMoathlyBillO-isDirtyO or 
this-getBillPaymeatO-isDirtyO); 

} 



This hard-coded approach, although straightforward, is 
both tedious and error-prone. It is tedious because business 
developers shouldn't have to deal with technical issues like 
dirty checking or distributed garbage collection. They 
should focus instead on business-specific processing. 

Moreover, this is enor-prone because it can be difficult to 
detect if the developer makes a mistake. For example, a new 
reqxurement could make the window display address infor- 
mation. In addition to repainting the window, the developer 
would also need to modify their hand-coded methods. But 
the developer might forget to update the isDirty( ) or release( 
) methods. Such errors can be difficult to locate. (Readers 
who have debugged memory leaks will certainly agree.) 

Instead, an architecture mechanism should encapsulate 
the propagation of these technical messages. When a mes- 
sage needs to be forwarded generically, to all objects in an 
LUW, the architecture should handle it. Sudi a capability 
would free biisiness developers from worrying about these 
technical details. FIG. 183 illustrates a Hand-crafted Mes- 
sage Forwarding scheme. 

Therefore, an architecture "bag" will represent the busi- 
ness objects in a particular LUW. This bag, or collection, 
will hold onto each business object. Then, when the bag 
receives a message like saveDataChanges( ) or release( ), it 
simply forwards the message to each member business 
object, 

FIG. 184 illustrates a Generic Message Forwarding fea- 
ture. 

Each LUW must have its own bag. This enforces the 
Isolation property (of AGD) for LUWs. That is, one LUW 
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should not affect another LUW. For example, if the Account 
Payment and Account Services activities have separate 

LUWs, they Avill correspondingly have their own bags. ; 

Then, calling saveDataChanges( ) on the Account Payment AbstractLmyA£^vity:;savcDataChangcsO { 

. '-^'"p Jz^J,, '-M-wt^v J ff Propagate along the save message to all busmess 

activity will forward saveDataChanges( ) to only those 5 // objects in my LUW. SubcUsses don't even need to , 

business objects owned by Account Payment. // know about this method. 

The bag also helps ensure the Atomicity property (also of this-getLUWContextQ-saveDataChangesO; 

ACID) for LUWs. It provides a single, atomic interface into ^ . 
the multiple business objects of the LUW. By design, it 

ensures that all business objects receive the same architec- lo This assumes that business objects were put into the LUW 

ture messages. Context in the first place. The context object can be passed 

Hius, the scope of a bag is an LUW. In addition, a bag in when instantiating an object, tran^arently by the persis- 

provides contextual information for the LUW— i.e., which ^ence and streaming frameworks, etc. 

business objects that LUW uses. The architecture bag there- An LUW Context can collaborate with a Request Batcher, 

fore models the LUW Context, and will be named as such. 15 ^ requests are batched for transmission to the data store 

Benefits Rather than stonng the batcher globally, each context and 

_ ^ hence model can have its own manager. This allows multiple 

Encapsulation. LUW Context hides lechmcal details of domain models, in multiple contexts, to send transactions 

persistence, garbage coUecUon, etc., from business simultaneously but independently. Then, whenever a busi- 

developers. Some of the Known Uses have managed to Qg^s object requests an access or update, its request will be 

hide this framework, in entirety, from business logic. 20 intercepted by the model's particular Request Batcher. The 

Robustness. This approach guarantees that each business batcher then holds these requests until the activity — which 

object in the LUW receives forwarded messages. There owns the LUW — tells the batcher to send them, 

is no longer the chance of a developer forgetting to The LUW Context holds onto all domain objects in a 

include a particular business object in a group message. particular model. It can therefore collaborate with an Iden- 

AppHcation Maintainability. As the application require- ^ tity Registration Manager to enforce object uniqueness 

ments change, the set of business objects in an LUW "^^^ ?S u i i 

. • r^mr j The Potential Vanables pattern, which provides local 

can change without mpactmg the genenc, LUW code ^ ^^^^ first version of the Object Solutions 

For example a foture version of the Account Payment ^^^^ „ lUWs use this approach, then LUW 

wmdow could also display Address information. This r>«„f^^* „ i i^«t;«« #k« t ttw «»,«c-o 

L- L-.-..t. TTTTT7 ^ ^0 Coutcxt IS E uatuTal location to store the LUW phase 

mtroduces a new busmess object mto the LUW. Yet it variable 

would not require updating saveDataChanges( ), or ,^ ^ ^^^^^ ^ 

releasee ) methods, as it would have previously. ^^^^^^^^^ ^^^^^^^ ^^^^^^^ LUW Context, 

Performance. LUW Context can dramatically improve as intermediary, can provide a simple public interface which 

performance in a distributed environment. By nature, it 35 supports setting and querying the phase variable, 

batches up messages for a group. This can reduce Request Batcher 

network messaging, PIQ iUustrates a flowchart for a method 18500 for 
For example, consider a search window which has instan- batching logical requests for reducing network traffic. A 
tiated 30 business objects. Releasing those objects, if group of business objects necessary for a transaction are 
the messages were sent independently, would require 40 provided and managed in a logical unit of work in operations 
30 network messages. However, with LUW Context, a 18502 and 18504. In operations 18506 and 18508, logically- 
single message can go from the client to the server. related requests received from the logical unit of work are 
Then, within the server executable, the LUW Context grouped into a single network message which is then stored, 
forwards release( ) to the 30 member objects. This is far The message is sent in operation 18510 upon receiving an 
less costly than using the network for that messaging. 45 order to send the message. 

Because of this message batching, some readers may Optionally, update and retrieval transactions may be 

confuse LUW Context with Request Batcher It is true grouped into a single network message which is stored. The 

that both reduce the number of network messages. message may be sent upon receiving an order to send the 

However, the former is concerned with supporting a message. As another option, the requests from the message 

family of generic, architecture messages, like isDirty( ) 50 may be unpackaged at a point across a network and data 

and refresh( ), on a single atomic object. The latter is changes may be persisted. In a fiirther optional embodiment, 

concerned with grouping database requests into a responses to the requests may be received and the responses 

physical package, for un-batching at the server may be bundled into a reply. In one embodiment, the 

Although both have similar principles and requests in the message may be sorted. In such an 

characteristics, they solve different problems and arc 55 embodiment, the requests in the messages may also be 

implemented differently. separated into submessages. 

Architecture Extensibility. LUW Context models the When domain objects request themselves, minimize the 

LUW as an actual object in the software. Any other impact of network traffic. 

architecture processing which executes 00 a per-LUW Individual Persistence assigns responsibility for data 
basis can also be coded there. (See the Related Patterns 60 access to individual business objects. Then, each business 
section for examples.) object can retrieve, update, insert, and delete its data from a 
Hiis pattern seeks to hide the message propagation from persistent store independently of other objects. This pro- 
business logic. In fact, messaging to an LUW Context can be motes encapsulation and reuse across business transactions, 
hidden completely in an architecture superclass. Previously, FIG. 186 illustrates the aianner in which the present 
saveDataChanges( ) wouldVe been coded specifically in 65 invention sends requests 18600 independently, 
each concrete activity dass. LUW Context allows it to be Thus, an LUW which uses multiple business objects will 
abstracted, as in: correspondingly have multiple requests. Hiis might suggest 
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that each independeDt request communicate independently A request may also not be allowed to proceed until all 

with data access services. Then, each logical request would dependent requests are completed. A plurality of transac- 

translate into its own physical, network message. lions may each use the same sorting rules for preventing 

Every network message imposes a certain amount of deadlocks. Optionally, the class represented by each request 

overhead, independently of its contentsor length. This 5 may be determined so that the sorting rules may be based on 

implies that multiple, small-grained messages have more a class type. As another option, the sorting rules may include 

overhead than a single, large-grained message. Many referential integrity rules which ensure that references 

networked-constrained environments cannot tolerate this between two relational tables are valid. In such a situation, 

additional overhead. Such environments should minimize a Linear ordering of requests may also be created based on 

the impact of this network traffic. lo the referential integrity rules. The numbering of the position 

Hicreforc, a high-performance transaction should batch of the request in the linear ordering may also be the weight 

its logical requests into a single network message. Moreover, of that request so that requests with lower weights are 

a framework should handle this packaging, transparently to processed before requests with higher weights, 

application logic. In an update transaction, order requests for referential 

FIG. 187 illustrates a manner in which the present inven- 15 integrity and deadlock avoidance, 

tion registers requests. Referential Integrity 

A Request Batcher 18700 object will group logically- Referentiallntegrity (RI) ensures that references between 

related requests. All requests will register with this coordi- two relational tables are valid. That is, foreign keys in one 

nating object, rather than sending themselves immediately table mxist refer to existing primary keys in another table, 

and independently to their server or database. The batcher 20 For example, RI rules could reqmre that all accounts have a 

win then store these requests together, until told to send customer. Then, values in account.cust_Jd would need 

them as a unit. This batching applies equally well to update matching values in customencust^d. 

and retrieval transactions. Mission-critical RDBMSs can enforce RI at run-time, 

A corresponding Request "Unbatcher" 18702 on the Then, if a modified foreign key does not match an existing 

server will unpackage the bundled network message. 25 primary key, the database prevents the update. 

Finally, this Unbatcher willbimdle the network response and Continuing the example, a transaction may insert a new 

send it back to the Request Batcher. customer and its new account. If the transaction inserts the 

Benefits account first, account.cust_id will refer to a non-existent 

Performance. Sending a single message of multiple customer. The RDBMS wiU raise an error, thereby failing 

requests, as opposed to multiple messages of single 30 the transaction. Instead, the account request should run after 

reqiiests, improves commtmication performance. customer request. 

Dynamic. Batching and sorting requests is transparent to Deadlock Avoid^oe ^ ^ . 

the requests themselves. Requests do not know that a Even without RI, request ordenng remains an issue, 

particular transaction contains them. ITiis dynamic ^ I°^^g^^f ^ transaction A orders ci^tomer before account 

relationshipallowsanytypeofrequesttobepartofany Conversely, a concurrent transacfaon B orders account 

transaction at run-time, before customer. A will request a lock on the customer table, 

„ , , , ^ while B will request a lock on the account table. A must wait 

Scaleability. In an asynchronous or multi-threaded for B to complete and release its account lock. Yet B cannot 
enviromnent, an application could use multiple Request j^^^ ^ ^^j^^^ ^^^^^ 
Batchers. For example each LUW could have its own ^ ^^j^ transactions wiU deadlock. Many transaction- 
batcher. A batcher needs to store state while budding j ^ms would simply fail both transactions, 
Oie batch, as requests register. Usmg mulUple instances ^ jj^^.^^, ^oth transactions may otherwise have 
facilitates registration for, and sendmg of, multiple ^^^^^ vaJid 
batches simultaneously. Users can then multi-task Traditional Approach 

white other, time^onsuming requests process in the Traditionally, transactions have hard-coded deadlock 
background. avoidance and RI. Each transaction has called its own update 
Hiis simultaneity can also be supported with one, multi- module. Each hand-crafted module has ordered mult^)le 
threaded batcher. In this case, each request registers SQL statements, according to these rules, 
along with its unique transaction id. However, with Individual Persistence, a transaction no 
Centralization, The batcher has visibility over all requests 50 longer maps to a centralized module. Instead, independent 
in the LUW. This provides a centralized point to sort requests register for the transaction in an ad-hoc manner, 
these requests, thereby supporting referential integrity FIG. 189 illustrates an Ad Hoc Registration feature, 
and deadlock avoidance. Moreover, an account has no hard-coded '^knowledge'* 
Request Sorter that it should persist after a customer. Hiis independence 
FIG. 188 illustrates a flowchart for a method 18800 for 55 provides flexibility any business object can request an 
sorting requests that are being unbatched from a batched update without concern for other business objects. A frame- 
message. A group of business objects necessary for a trans- work which constrains the request order must support this 
action are provided in operation 18802. Logically-related flesribility. 

requests received from the business objects are grouped in Therefore, an update transaction should sort its requests 

operation 18804. Sorting rules and/or sort weights are 6o before sending them to the data server. The sorted result will 

obtained in operation 18806 and, in operation 18808, the conform to RI rules. Then, across update transactions, all 

requests in the message are sorted and placed in a specific customer requests can appear before all account requests. In 

order determined from the sorting rules and/or the sort addition, every transaction will use the same sort algorithm, 

weights. The sorted requests are batched into a single That will prevent deadlocks. 

message which is sent to a data server where the requests are 65 Multiple requests can no longer send themselves directly 

unbimdled from the message in the specific order (see to the server, in an ad hoc fashiort Instead, they must register 

operations 18810, 18812, and 18814). with a centralized object, which can sort them first. A 
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centralized Request Sorter will order multiple requests copy of the common business object is created for each of 

before finally sending the transaction. the logical units of work such that the copy of the business 

FIG. 190 illustrates a manner in which the present inven- object for one logical unit of work becomes a separate 

tion sorts requests by weight. instance from the copy of the business object for another 

The sorter 19000 will have visibility to sorting rules, or 5 logical unit of work. Each copy of the business object knows 

even weights, to determine this order. The rules can typically the context of that copy of the business object in relation to 

be based on the class type. Before sending the transaction, the associated logical unit of work. Upon receiving a request 

the sorter can ask each request which class it represents. In to make changes to a copy of the business object of one of 

this manner, the sorter can re-order the requests appropri- the logical units of wodc in operation 19106, that particular 

ately. lO copy of the business object is changed while the other copies 

Benefits of the business object are not changed. It is then verified in 

Separation of Concern. This sorting pattern hides the operation 19108 that only one copy of the business object 

technical details and complexity of RI from business has been changed and the common business object is 

logic. Applications avoid hard-wiring customized RI updated in operation 19110 based on the change to the copy 

rules for its transactions. 15 of the business object. 

Maintainability. RI rules can easily be changed without ^ Abusinessobjectmay optionally be passed as a parameter 

impacting appKcation code. Granted, this does not ^^^^ ^« ^ ^^^^ 

happen frequently in production. ^^f "^^^^^l "^^y be created which includes a duph- 

„ 2. .„ . , catc of the original data and excludes a context vanable. As 

Reusabihty. The generic R^uest Sorter uses universal ^ ^^^^^ ^^^^^ ^ ^ ^^^^ ^^^^ ^^^^ ^ 

sorting rules, or weights. These rules are global aaoss ^^^^^ ^ ^ ^ ^^^^^ ^ ^ ^^^^^ 

busmess processes. Moreover, the rul^ are based on ^^^^^ ^ ^^^^^ ^^^^ ^^^j^^^ ^^^^^ 

existmg, reusable busmess objects. Therefore, new of work. 

appUcatioDS can reuse the sorter, as well. y^^^^ ^^^^^^^ ^ ^^^^^^ ^^^^ 

Visibility. If RI enforcement is distributed across appli- 25 at least one of a single focus of a window that is being 

cation logic, it can be difficult to get a complete picture created and a parameter in an explicit parameter-passing 

of the referential rules. Request Sorter centralises those mechanism. Additionally, the copies of the business objects 

rules (i.e. weights) in one, visible place. may be created from a same retrieved data stream. As a 

A complete, linear ordering of all domain classes can be further option, receiving a request to make changes to a copy 

created, based on the RI rules. Each class will have a unique 30 of the business object of one of the logical units of work and 

position in the ordering. This position is the class* weight for changing that copy of the business object may further 

the sorting algorithm. Requests for domain objects with include the broadcasting of the change to the other logical 

lower weights will always appear before requests with imits of work. 

higher weights. Support multiple business LUWs within an MVC-based 

For example, consider the ordering: 35 architecture. Manage these LUWs concurrently yet 

27. . , , separately, thereby preserving the Isolation property of 

28. Customer AQD. 

29 MeterRead Multi-tasking allows the user to complete several different 

' business functions independently of each other. Those func- 

^ 40 tions which are business LUWs must process conciu-rentiy 

31, Meter separately. For example, a user could establish a new 

32, MonthlyBill customer account while separately verifying bill details for 

33, . . . another customer. 

Hiis satisfies the RI rule mentioned earlier, because Providing for these multiple LUWs demands mechanisms 

Customers have a lower weight (28) than Accounts (30). 45 which ensure integrity. Specifically, as with any LUW, a 

Thus, requests for customers will appear in any transaction primary LUW must isolate its own changes. It is an inde- 

before requests for accounts. As long as the order satisfies pendent workspace which prevents its changes from affecl- 

every RI rule, the request sorter can use such a linear ing other LUW. 

ordering. However, an MVC-based 00 architecture does not natu- 
This sort ordering can be created programmatically, A sort 50 rally support this requirement. With MVC, the domain 
generator can convert pairwise relationships into linearly- model stores all data changes. Windows are merely a view 
ordered weights. Then, the Request Sorter could use an into this model, and they have little business data of their 
algorithm like Quicksort to do the actual sorting. own. In addition, MVC model objects have no idea which 
(Alternatively, object requests could be sorted as they are views are using them. Instead, the model anonymously 
registered, a la Insertion Sort.) 55 broadcasts its data changes, and all views on the model 
A centralized store-and-forward site must hold requests, respond by updating themselves. This synchronizes win- 
before they send themselves to the server. Otherwise they dows with their business data. Thus, MVC allows multiple 
cannot be sorted as a group. Request Batcher provides a views to simultaneously display, and be refreshed by, a 
centralized place to attach a sorter. single copy of the model data. 

Separate Models 60 FIG. 192 illustrates the MVC Implementation with Global 

FIG. 191 illustrates a flowchart for a method 19100 for Model, 

assigning independent copies of business data to concurrent Unfortunately, this benefit of MVC introduces a problem, 

logical units of work for helping prevent the logical imits of A globally-shared domain model does not naturally separate 

work firom interfering with each other. In operation 19102, concurrent LUWs. It puts a burden on business "activity" 

multiple logical units of work operating concurrentiy are 65 objects, which coordinate the high-level business processing 

provided. Each of the logical units of work manipulate at across their domain models. Each activity has to either avoid 

least one common business object. In operation 19104, a overlap or know specifically how it affects the model. 
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Consider a telecommunications system^ with two separate 
business LUWs for paying bills and adding new services, 
like call waiting. An end user might launch windows for 
these two LUWs simultaneously. This would albw the user 
to multi-task while conversing with the customer. 

Both windows display Account and Customer informa- 
tion. In addition, the Account Services window actually 
modifies the Account object, whereas the Account Payment 
window does not. Making a payment only modifies the Bill 
Payment object. Both windows, using MVC, could share the 
same Account 101 instance. 

It is not atypical for custom architectures to have generic 
mechanism for persistence and transactions. For example, 
the architecture could use a straightforward mechanism 
which automatically saves all business objects within an 
LUW. Then, when the user saves the Account Payment 
window, the changes to Account 101 would be accidentally 
saved as welL The user would then not be able to later cancel 
changes on the Account Services window. This violates the 
isolation of the two LUWs. 

A similar problem might arise with a garbage collection 
framework, which explicitly destroys all instances once the 
LUW has completed. In this case. Account Payment would 
need to ensure it did not explicitly free the memory for 
Account, while Account Services was still using it. 

Therefore, using a global, MVC model may preclude 
using other architecture mechanisms. To avoid the problems 
of overlapping saves or releasing memory prematurely, the 
windows could have additional code to ensure the LUWs 
remain separate. However, adding application-spedfic code 
in this manner, to handle a global technical requirement, is 
imdesirable. 

Instead, business LUWs should be able to modify domain 
data independently of each other, transparently in the archi- 
tecture. In addition, each data change should unambiguously 
belong to a single, originating LUW. 

Modem Object Transaction Monitors promise to provide 
this capability. These products will handle locking, tracking 
which LUW has made changes to which piece of data, etc. 
However, in the absence of an OTM, a custom architecture 
needs a different approach. 

Therefore, separate business LUWs by giving each LUW 
separate copies of business data. 

Rather than using a globally-shared model, each btisiness 
LUW will own a private, scratchpad copy of its domain 
model. This satisfies the independence requirement. A busi- 
ness object in one model will automatically be a separate 
instance from a business object in another model, even if 
they share the same functional identity. For example, simul- 
taneously opened payment and services windows would 
have separate copies of Account 101. 

Then, changes made to a particular instance will only be 
reflected in the LUW which created and points to that 
instance. This contrasts with a single, globally-shared 
model. The latter would simultaneously reflect changes 
across multiple LUWs. 

FIG. 193 illustrates the Separate Models for Separate 
Business LUWs 1»300,19302, 

The aforementioned telccomm;mications example had 
two separate business LUWs for the account payment and 
account services functions. Although both activities may be 
related by the same logical account, this pattern gives each 
a different context copy. Then, when the customer represen- 
tative cancels the addition of call waiting, she can still save 
the payment details. 
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FIG. 194 illustrates the Canceling of one LUW 19400 
IndependenUy of Another LUW 19402. 

Thus, using Separate Models preserves the integrity of 
business LUWs. It allows each LUW to easily save or cancel 
5 independently. 

This pattern is not intended to allow different LUWs to 
simultaneously change their different physical copies of the 
same logical entity. In fact, if both windows modified their 
Account 101 copy, one of the LUWs would fail. 
(Mechanisms like optimistic locking would detect the data 
integrity conflict.) 

Precisely for this reason, a good UI design doesn't typi- 
cally allow simultaneous but separate LUWs to update the 
same data. And this was not an issue in the example above. 
Updates to the Account object occur on the Account Ser- 
1^ vices window but not the Account Payment window. 
Benefits 

Isolation. Most fimdamentally, this pattem solves the 
Isolation requirement of ACID. It ensures that each 
LUW has its own "working storage" copies of business 
20 data. 

TVansparency. Separating models can be done in an archi- 
tected fashion, as outlined in the implementation sec- 
tion. The separation of LUWs — ^which is a technical 
issue — can be hidden completely firom business logic. 

25 Imagine instead that LUWs didn't have their own copies. 
Then, each operation might need an additional argu- 
ment: the LUW owning the data change. This would 
pollute application code with an extra "transaction ID" 
argument, as in set6alance(newBalance, 

30 transactionid). As previously mentioned, this is only 
required in the absence of an Object Transaction Moni- 
tor. An OIM can transparently manage the transaction 
Id with the thread, without including it as an explicit 
argument. 

35 Uniformity. Application developers don't need to know 
about which objects may or may not be used by other, 
concurrent LUWs. 
The following implementation assumes that the LUW 
Context pattem is used to help separate the LUWs. 
40 Each instance of a business object knows which LUW 
owns it. That is, each instance knows its context. By 
definition, context gives something a scope, a frame of 
reference, a relationship to other things. To provide this 
relationship, an actual LUW Context object will hold onto* 
45 business objects which share a business LUW. 

In addition, each biisiness object can point to its context. 
In that manner, business objects know their LUW. This 
could be useful, for example, while building a domain 
model. Then, the parent object could propagate its context to 
50 a Unked, child object 

Business objects owned by the same business LUW share 
the same LUW Context, whereas different LUWs have 
different contexts. Each context therefore contains its own 
"working-storage" copy of the model This delineates an 
55 individual workspace, or scratchpad, for each LUW. 

At a higher level, each activity object vs^ich represents a 
business LUW has its own context object. That context 
remains with the activity throughout its entire lifecycle. For 
initialization, creating a new LUW activity also creates a 
60 new context instance for that activity. This context wfll then 
be passed downwards, to all business objects, as part of 
navigation. 

Eventually, when the activity closes, it releases its LUW 
Context. This correspondingly releases all business objects. 
65 They can then be garbage collected, because the only LUW 
using those objects just closed. A context's Lifecycle there- 
fore corresponds directly to its activity's lifecycle. 
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Preserving Context Boundaries 

Every context has a scope which limits the business LUW. 
This context boundary cannot be violated with objects from 
other LUW Contexts. For, the same instance of a business 
object cannot live in two different contexts. Otherwise, 
changes made to that instance would affect two different 
LUWs. 

It is often necessary, however, to pass a business object as 
a parameter from one context to another. For example, a user 
may open up a customer details window based on a selection 
from a search window. The selected customer becomes the 
focus of the new window, but it was instantiated in the 
search context. It is the responsibility of the details window 
to take the passed-in customer and make a context copy of 
it. A context copy duplicates the original's data, excluding 
the context variable, which is re-set to the new context. The 
copied customer can then be safely used and modified within 
the details context. 

A business object can be passed as parameter to another 
context as: 

the single focus of a window that is being created 
a parameter in an explicit parameter-passing mechanism 
For example, when a business object is the focus of a new 

activity, the launching activity could instantiate the new 

activity as follows: 

MeterMaintenanceActivity::prorateMeterRead(MeterRead 
aMeterRead) 
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-continued 



// then use leflccUon to call the right public setter on the activity. 
iiewPiorateActivity.Teceive(aConectedMeterRead, 
'wtConectedRead"); 
// Other inltialisatioa here „. 
aewFiorateActivity.startupO; 
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// Creates a new activity to prorate <aMetetRead>. This will manually 
adjust the 

// read charges, based on corrections the location, the ofSce, etc. 
// Pseudo-code below. 

1} Create the new activity instance by reflection, based on the class 
name, and 

// give it a new context and <&MeteiRead> as focus. 
newProrateActivity - this.newActivity( 
this-prorateMeterReadClassNameO. 
aMeterRead); 
// Other initialisation here ... 
newProiateActivity.startt^ 0; 
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} 



The ne wActivity( ) architecture method instantiates a new 
activity, instantiates a new context, and creates a context 
copy of aMeterRead that the new activity can use. 

Sometimes an activity cannot get enough information 
simply by navigating from the focus. Non-focus information 
that must be passed as an additional parameter could be 
handled in the following manner: 
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MeterMaintenanceActivity::prozateMeterReadWithConectioa( 
MeteiRead oiiginalMeterRead, MeterRead correctedMeterRead) 

{ 

// Creates a new activity to prorate <originaIMeterRead> based on 
measurements 

// in <correctedMeterRead>. Pseudo-code below. (Duplicates some 
code above 
// for claiiAcation.) 

// Create the new activity instance by reflection, based on the class 
name, and 

// give it a new context and <originalMeterRead> as focus. 
newProrateActivity - this.newActivity( 

this.proTateMeterReadClassNaine(), 

originalM eterRead) ; 
// Pass along the corrected read, as well. Hiis will create a context 
copy and 
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Here, the rcceive( ) framework method allows any bxisi- 
ness object to be passed across the context boundary. The 
receiving activity will automatically create a context copy 
and then call the specified setter method, with the copy as 
argument. The setter is application-specific, and it allows the 
activity to handle and store the context copy wherever it 
wants. 

FIG. 195 illustrates the Context Copying Protects Context 
Boundaries. 

A dirty object should not be safely copied into a new 
LUW context. Otherwise, the second LUW would begin 
using information that was half -completed in the first LUW. 
Again, this violates the isolation requirement. The second 
LUW could save its changes before the first LLTW. This 
means the first LUW couldn't imdo any changes it had made 
to the dirty object. Instead, to avoid this problem, an 
exception should be thrown when trying to copy dirty 
objects across contexts. This disallows users from beginning 
a new LUW based on half-entered data. 

Thus, context copying allows LUW contexts to share 
parameter information whUe preserving context boundaries. 
Persistence Caching 

Although LUW contexts manipulate separate copies of 
business objects, they can often share the same retrieved 
data stream. For example, when a workstation retrieves data 
for Customer ABCD, the returned stream can be stored in a 
global cache. If another context wants to later instantiate its 
own copy of Customer ABCD, it can reuse the details stored 
in the stream cache. This improves performance, by avoid- 
ing a redundant request to the remote data store. 
Context "Refresh" 

Each LUW, while working on its data, is independent of 
the other LUWs. From that perspective, each LUW context 
manipulates data that, to its knowledge, is the most current 
information from the data store. One instance's changes 
remain invisible to another copy of the same business entity, 
during the course of normal processing. 

However, when an LUW context successfully commits 
changes, it will have more current data than other contexts 
which it intecsects. This up-to-date data can be broadcast and 
shared with the other contexts. These contexts can then 
decide to transparently incorporate the changes or not. 

This refresh mechanism can be complex to bmld, and it 
requires an understanding of locking issues. For example, 
docs the window have any changed data whidi might 
conflict with the new data? This would make the changes 
which hadn't yet been committed invalid, and the user 
would need to be notified. 

Although only a few embodiments of the present inven- 
tion have been described in detail herein, it should be 
imderstood that the present invention may be embodied in 
many other specific forms without departing from the spirit 
or scope of the invention. Therefore, the present examples 
and embodiments are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the 
appended claims. 
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What is claimed is: 

1. A method for using a view configurer within a multi- 
layered architecture for managing the relationship between 
a plurality of activities and a plurality of views, with 
communication between layers being transmitted exclu- 
sively downward allowing the plurality of views to com- 
municate directly with the plurality of activities but not 
alloviring the plurahty of activities to communicate directly 
with the plurality of views, comprising the steps of: 

(a) registering a server-based view configurer with a 
client-based activity factory to indicate an interest in 
initiated activities, wherein the initiated activities are 
made up of business logic, and wherein the plurality of 
the initiated activities are executed on a client and are 
in communication with the server; 

(b) instructing a first activity to initiate a second activity, 
wherein the first activity and the second activity origi- 
nated from the plurality of initiated activities, wherein 
the first activity is associated with a first view, and 
wherein the first activity receives instructions to initiate 
the second activity from the first view; 

(c) initiating an instance of the second activity; 

(d) receiving a broadcast notification that an initiation 
event of the second activity has occurred, wherein the 
broadcast notification is transmitted by the second 
activity, and wherein the broadcast notification is 
received by the view configurer absent the second 
activity knowing of the existence of the view config- 
urer; 

(e) receiving a reference to the instance of the second 
activity, wherein the reference is received by the view 
configurer; 

(f) determining a second view to launch in response to the 
receipt of the broadcast notification and the reference, 
wherein the second view is based on predetermined 
criteria, wherein the predetermined criteria is user 
preferences, an experience level of a user, security 
profiles, and workflow settings, and wherein the second 
view is determined by the view configurer, 

(g) associating the second view with the second activity; 
and 

(h) displaying the second view. 

2. A method as recited in claim 1, wherein the second 
activity is allowed to run without a corresponding view. 

3. A method as recited in claim 1, wherein the second 
activity operates on a machine separate from a machine of 
an end user. 

4. A method as recited in claim 1, further comprising the 
step of sending a request to be notified when a new instance 
of an object is created. 

5. A method as recited in claim 1, further comprising the 
step of reading from a configuration file for obtaining 
configuration information. 

6. A computer program embodied on a computer readable 
medium for using a view configurer within a multi-layered 
architecture for managing the relationship between a plu- 
rality of activities and a plurality of views, with communi- 
cation between layers being transmitted exclusively down- 
ward allowing the plurality of views to communicate 
directly with the plurality of activities but not allowing the 
plurality of activities to communicate directly with the 
plurality of views, comprising: 

(a) a code segment that registers a server-based view 
configurer with a client-based activity factory to indi- 
cate an interest in initiated activities, wherein the 
initiated activities are made up of business logic, and 
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wherein the plurality of the initiated activities are 
executed on a client and are in communication with the 
server; 

(b) a code segment that instructs a first activity to initiate 
a second activity, wherein the first activity and the 
second activity originated from the plurality of initated 
activites, wherein the first activity is associated with a 
first view, and wherein the first activity receives 
instructions to initiate the second activity from the first 
view; 

(c) a code segment that initiates an instance of the second 
activity; 

(d) a code segment that receives a broadcast notification 
that an initiation event of the second activity has 
occurred, wherein the broadcast notification is trans- 
mitted by the second activity, and wherein the broad- 
cast notification is received by the view configurer 
absent the second activity knowing of the existence of 
the view configurer; 

(e) a code segment that receives a reference to the instance 
of the second activity, wherein the reference is received 
by the view configurer; 

(f) a code segment that determines a second view to 
launch in response to the receipt of the broadcast 
notification and the reference, wherein the second view 
is based on predetermined criteria, wherein the prede- 
termined criteria is user preferences, an experience 
level of a tiser, security profiles, and workflow settings, 
and wherein the second view is determined by the view 
configurer; 

(g) a code segment that associates the second view with 
the second activity; and 

(h) a code segment that displays the second view. 

7. A computer program as recited in claim 6, wherein the 
second activity is allowed to run without a corresponding 
view. 

8. A computer program as recited in claim 6, wherein the 
second activity operates on a machine separate from a 
machine of an end user. 

9. A computer program as recited in claim 6, further 
comprising a code segment that sends a request to be notified 
when a new instance of an object is created. 

10. A computer program as recited in claim 6, further 
comprising a code segment that reads from a configuration 
file for obtaining configuration information. 

11. A system for using a view configurer within a multi- 
layered architecture for managing the relationship between 
a plurality of activities and a plurality of views, with 
communication between layers being transmitted exclu- 
sively downward allowing the plurality of views to com- 
muiucate directly with the plurality of activities but not 
allowing the plurality of activities to communicate direcUy 
with the plurality of views, comprising: 

(a) logic that registers a server-based view configurer with 
a client-based activity factory to indicate an interest in 
initiated activities, wherein the initiated activities are 
made up of business logic, and wherein the plurality of 
the initiated activities are executed on a client and are 
in communication with the server; 

(b) logic that instructs a first activity to initiate a second 
activity, wherein the first activity and the second activ- 
ity originated from the plurality of initiated activities, 
wherein the first activity is associated with a first view, 
and wherein the first activity receives instructions to 
initiate the second activity from the first view; 

(c) logic that initiates an instance of the second activity; 
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(d) logic that receives a broadcast notification that an 
initiation event of the second activity has occurred, 
wherein the broadcast notification is transmitted by the 
second activity, and wherein the broadcast notification 
is received by the view configurer absent the second 
activity knowing of the existence of the view config- 
urer; 

(e) logic that receives a reference to the instance of the 
second activity, wherein the reference is received by the 
view configurer; 

(f) logic that determines a second view to laimch in 
response to the receipt of the broadcast notification and 
the reference, wherein the second view is based on 
predetermined criteria, wherein the predetermined cri- 
teria is user preferences, an experience level of a user, 
seciirity profiles, and workflow settings, and wherein 
the second view is determined by the view configurer; 

(g) logic that associates the second view with the second 
activity; and 

(h) logic that displays the second view. 
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12. A system as redted in claim 11, wherein the second 
activity is allowed to run without a corre^onding view. 

13. A system as recited in claim 11, wherein the second 
activity operates on a machine separate firom a machine of 
an end user. 

14. A system as recited in daim 11, further comprising 
logic that scads a request to be notified when a new instance 
of an object is created. 

15. A system as redted in claim 11, fiirther comprising 
logic that reads from a configuration file for obtaining 
configuration information. 

16. A method as recited in claim 1, wherein the activity 
factory broadcasts the notification of the startup event of the 
activity. 

17. Amethod as redted in claim 1, wherein a new instance 
of each of the plurality of activities is created by the activity 
factory. 
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